Transaction exchange platform with a pause microservice to pause processing of workflows

ABSTRACT

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. Microservices on the transaction exchange platform may interact with the transaction objects based on configured workflows associated with the transactions. Processing on the transaction exchange platform may facilitate clearing and settlement of transactions. Some aspects may provide for pausing the processing of transactions during a workflow. Other aspects may provide for a messaging microservice that permits communications between the transaction exchange platform and external third-parties.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. application Ser. No.17/389,045, filed on Jul. 29, 2021 and entitled “Transaction ExchangePlatform with Watchdog Microservice,” which is a continuation of U.S.application Ser. No. 16/723,545 (now U.S. Pat. No. 11,080,120), filed onDec. 20, 2019 and entitled “Transaction Exchange Platform with WatchdogMicroservice,” the entireties of which are incorporated herein byreference.

This application is also related to the following U.S. patentapplications, filed on the same day:

-   -   Attorney Docket No. 009033.00536, entitled “Transaction Exchange        Platform with a Messenger Microservice to Update Transactions”        and filed concurrently herewith;    -   Attorney Docket No. 009033.00537, entitled “Transaction Exchange        Platform with a Watchdog Microservice to Handle Stalled        Transactions” and filed concurrently herewith; and    -   Attorney Docket No. 009033.00670, entitled “Transaction Exchange        Platform Defining Conditions for the Processing of Transaction        Objects” and filed concurrently herewith.        Each of the related applications is incorporated by reference        herein in its entirety for all purposes.

FIELD OF USE

Aspects of the disclosure relate generally to a transaction exchangeplatform. More specifically, aspects of the disclosure may provide forpausing transactions as the transactions are processed using a streamingdata platform.

BACKGROUND

Computer systems and applications have revolutionized the handling oftransactions and greatly accelerated clearing and settlement processes.Software solutions have been created to facilitate processing,validation, and approval of transactions. These systems serve tointerface transaction originators with clearing and settlementoperations, allowing transactions to flow between enterprises andfacilitating the movement of trillions of dollars per year. Yetregulations, security, and risk management processes have grownincreasingly important and detailed, thereby complicating the approvaland settlement of transactions. Further, any issues with a transactionmay cause the transaction to fail out. The transaction would then haveto be re-worked, outside the system, and re-submitted. Alternatively,the transaction would be cancelled after being processed. Neither optionis desirable since it results in delays in processing transactions,which disrupt customer experiences, and hides visible functions, likefraud investigations.

Aspects described herein may address these and other shortcomingspresent in existing solutions. Novel aspects discussed herein mayimplement a transaction exchange platform using a streaming dataplatform and microservices to provide faster, more dynamic, and morerobust processing and approval of transactions. The novel transactionexchange platform may provide benefits such as improving the flexibilityand reliability of transaction approval and processing systems, whileoffering robust record keeping for transaction audit purposes. The novelplatform may also provide other benefits such as support for legacy andongoing operations, solving for new and changing requirements in today'senvironment, and adapting to future technologies

SUMMARY

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

Aspects described herein may relate to a transaction exchange platformusing a streaming data platform (SDP) and microservices to processtransactions according to review and approval workflows. The transactionexchange platform may receive transactions from origination sources,which may be added to the SDP as transaction objects. Microservices onthe transaction exchange platform may interact with the transactionobjects based on configured workflows associated with the transactions.Processing on the transaction exchange platform may facilitate clearingand settlement of transactions. Some aspects may provide for theprocessing of transaction objects to be paused, for example, based on arequest from an external party, missing information, fraudinvestigations, etc. To address missing information or fraudinvestigations, a messaging microservice may be used to communicate withparties external to the transaction exchange platform. Transactionobjects may be updated with the missing information or cleared of thefraud investigations. After being updated, the transaction objects maycontinue to be processed by the transaction exchange platform.

Corresponding apparatus, systems, and computer-readable media are alsowithin the scope of the disclosure.

These features, along with many others, are discussed in greater detailbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 depicts an example of a computing device that may be used inimplementing one or more aspects of the disclosure in accordance withone or more illustrative aspects discussed herein;

FIG. 2 depicts an example operating environment used to discussillustrative aspects of a transaction exchange according to one or moreaspects of the disclosure;

FIG. 3A depicts an example transaction exchange platform according toone or more aspects of the disclosure;

FIGS. 3B-3C depict example structures for microservices according to oneor more aspects of the disclosure;

FIG. 4 depicts an illustrative workflow as a directed acyclic graphaccording to one or more aspects of the disclosure;

FIG. 5 depicts an illustrative method for processing transactions on astreaming data platform according to one or more aspects of thedisclosure;

FIG. 6 depicts an example transaction exchange platform having aconfiguration interface according to one or more aspects of thedisclosure;

FIGS. 7A-7C depict illustrative changes to workflows, as graphs,according to one or more aspects of the disclosure;

FIG. 8 depicts an illustrative method for reconfiguring microservicesaccording to one or more aspects of the disclosure;

FIG. 9 depicts an example transaction exchange platform having asnapshot microservice and a watchdog microservice according to one ormore aspects of the disclosure;

FIGS. 10-15 depict illustrative methods for operation of the snapshotmicroservice and the watchdog microservice according to one or moreaspects of the disclosure;

FIGS. 16A and 16B depict examples of a transaction exchange platformaccording to one or more aspects of the disclosure;

FIG. 17 depicts an illustrative method for pausing processing of atransaction object according to one or more aspects of the disclosure;

FIG. 18 depicts an illustrative method for pausing processing of atransaction object and requesting additional information for thetransaction object according to one or more aspects of the disclosure;

FIG. 19 depicts an illustrative method for handling stalled transactionobjects according to one or more aspects of the disclosure;

FIG. 20 depicts an illustrative method for handling embargoedtransaction objects according to one or more aspects of the disclosure;and

FIG. 21 depicts an illustrative method for managing transaction objectswhen one or more conditions occur during processing of the transactionobject according to one or more aspects of the disclosure.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings, which form a part hereof, and inwhich is shown by way of illustration various embodiments in whichaspects of the disclosure may be practiced. It is to be understood thatother embodiments may be utilized and structural and functionalmodifications may be made without departing from the scope of thepresent disclosure. Aspects of the disclosure are capable of otherembodiments and of being practiced or being carried out in various ways.Also, it is to be understood that the phraseology and terminology usedherein are for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof.

By way of introduction, aspects described herein may relate to atransaction exchange platform using a streaming data platform andmicroservices to process transactions according to review and approvalworkflows. A transaction exchange platform, according to one or moreaspects discussed herein, may provide a version agnostic data streaming,reactive microservice solution that facilitates payment relatedworkflows to be executed. Although the term “microservice” is usedthroughout this disclosure, aspects are not limited to “microservices”as used in cloud computing contexts. Generally, as used herein“microservice” may refer to a technology process that does work on anobject on a streaming data platform in any given step of a workflow.Aspects discussed herein may refer to “approval” of transactions. Thisgenerally refers to the processing necessary to move a transactionthrough the transaction exchange platform from intake to output, anddoes not necessarily mean that the payment exchange platformaffirmatively approves the nature of the transaction. Instead,“approval” as used herein may refer to processing, validating, and/oraffirmatively approving a transaction according to a workflow indicatingthe steps necessary to process a transaction on the platform before itis ready for output to downstream processors. Some aspects may providefor the processing of transaction objects to be paused, for example,based on a request from an external party, missing information, fraudinvestigations, etc. To address missing information or fraudinvestigations, a messaging microservice may be used to communicate withparties external to the transaction exchange platform. Transactionobjects may be updated with the missing information or cleared of thefraud investigations. After being updated, the transaction objects maycontinue to be processed by the transaction exchange platform.

Before discussing these concepts in greater detail, however, severalexamples of a computing device that may be used in implementing and/orotherwise providing various aspects of the disclosure will first bediscussed with respect to FIG. 1 .

FIG. 1 illustrates one example of a computing device 101 that may beused to implement one or more illustrative aspects discussed herein. Forexample, computing device 101 may, in some embodiments, implement one ormore aspects of the disclosure by reading and/or executing instructionsand performing one or more actions based on the instructions. In someembodiments, computing device 101 may represent, be incorporated in,and/or include various devices such as a desktop computer, a computerserver, a mobile device (e.g., a laptop computer, a tablet computer, asmart phone, any other types of mobile computing devices, and the like),and/or any other type of data processing device.

Computing device 101 may, in some embodiments, operate in a standaloneenvironment. In others, computing device 101 may operate in a networkedenvironment. As shown in FIG. 1 , various network nodes 101, 105, 107,and 109 may be interconnected via a network 103, such as the Internet.Other networks may also or alternatively be used, including privateintranets, corporate networks, LANs, wireless networks, personalnetworks (PAN), and the like. Network 103 is for illustration purposesand may be replaced with fewer or additional computer networks. A localarea network (LAN) may have one or more of any known LAN topology andmay use one or more of a variety of different protocols, such asEthernet. Devices 101, 105, 107, 109 and other devices (not shown) maybe connected to one or more of the networks via twisted pair wires,coaxial cable, fiber optics, radio waves or other communication media.

As seen in FIG. 1 , computing device 101 may include a processor 111,RAM 113, ROM 115, network interface 117, input/output interfaces 119(e.g., keyboard, mouse, display, printer, etc.), and memory 121.Processor 111 may include one or more computer processing units (CPUs),graphical processing units (GPUs), and/or other processing units such asa processor adapted to perform computations associated with machinelearning. I/O 119 may include a variety of interface units and drivesfor reading, writing, displaying, and/or printing data or files. I/O 119may be coupled with a display such as display 120. Memory 121 may storesoftware for configuring computing device 101 into a special purposecomputing device in order to perform one or more of the variousfunctions discussed herein. Memory 121 may store operating systemsoftware 123 for controlling overall operation of computing device 101,transaction exchange platform software 125 for instructing computingdevice 101 to perform aspects discussed herein, machine learningsoftware 127, smart database 129, and other applications 131. Machinelearning software 127 may be incorporated in and may be a part oftransaction exchange platform software 125. In embodiments, computingdevice 101 may include two or more of any and/or all of these components(e.g., two or more processors, two or more memories, etc.) and/or othercomponents and/or subsystems not illustrated here.

Devices 105, 107, 109 may have similar or different architecture asdescribed with respect to computing device 101. Those of skill in theart will appreciate that the functionality of computing device 101 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc. For example,devices 101, 105, 107, 109, and others may operate in concert to provideparallel computing features in support of the operation of control logic125 and/or software 127.

One or more aspects discussed herein may be embodied in computer-usableor readable data and/or computer-executable instructions, such as in oneor more program modules, executed by one or more computers or otherdevices as described herein. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data typeswhen executed by a processor in a computer or other device. The modulesmay be written in a source code programming language that issubsequently compiled for execution, or may be written in a scriptinglanguage such as (but not limited to) HTML or XML. The computerexecutable instructions may be stored on a computer readable medium suchas a hard disk, optical disk, removable storage media, solid statememory, RAM, etc. As will be appreciated by one of skill in the art, thefunctionality of the program modules may be combined or distributed asdesired in various embodiments. In addition, the functionality may beembodied in whole or in part in firmware or hardware equivalents such asintegrated circuits, field programmable gate arrays (FPGA), and thelike. Particular data structures may be used to more effectivelyimplement one or more aspects discussed herein, and such data structuresare contemplated within the scope of computer executable instructionsand computer-usable data described herein. Various aspects discussedherein may be embodied as a method, a computing device, a dataprocessing system, or a computer program product.

Having discussed several examples of computing devices which may be usedto implement some aspects as discussed further below, discussion willnow turn to methods and techniques for implementing a transactionexchange platform.

Transaction Exchange Platform—Processing Streaming Transaction DataUsing Microservices

Aspects described herein may provide a transaction exchange platformimplemented using a streaming data platform (SDP) and a plurality ofmicroservices to process transactions according to workflowscorresponding to different transaction types. Microservices on thetransaction exchange platform may be configured to retrieve transactionshaving a current workflow stage that is assigned to the microservicefrom the SDP. The microservice may perform one or more steps of theapproval/review workflow for the type of transaction, update the statusof the object, and put it back to the SDP. Other microservices, later inthe workflow, may see that the current workflow status of a transactionindicates that earlier pre-requisite processing steps have completed andmay accordingly retrieve the transaction objects and perform theirrespective workflow steps. When the current workflow stage of atransaction indicates that all requisite steps of the workflow have beencompleted, the transaction may be removed from the SDP of thetransaction exchange platform and output to downstream systems forfurther processing.

A high level system 200 for processing transactions, such as payments,is illustrated in FIG. 2 . Transaction processing system 200 may broadlyillustrate the flow of transactions from origination source 205 throughto settlement systems 220. Transactions handled by system 200 may takeany suitable form, generally as payment transactions. Example types ofpayment transactions include: wires, automated clearing house (ACH)payments, checks, cashier checks, real-time payments (RTP), creditcards, and/or many other types of payment transactions. Other factorsthat may inform the “type” of a transaction may include whether thetransaction originates domestically or internationally, whether thedestination is domestic or international, an amount of the transaction,the identity of one or more financial entities associated with thetransaction, and the like. For purposes of the discussion herein, atransaction type may be relevant primarily for informing thereview/approval steps that should be applied to the transaction prior tofinal settlement.

Transactions may begin at origination sources 205. For example, if acustomer were to purchase a donut at a bakery using a credit card, thetransaction may be sent via a point-of-sale (POS) terminal at the bakeryto a payment processor. As another example, an investor may cause a wirepayment to be sent to their broker via a banking website. The bankingwebsite may receive the wire payment transaction and begin the processof facilitating settlement of the wire transaction via a transactionprocessing system 200.

Transactions may be routed to settlement systems 220 to effect thetransfer of the monies indicated in the transaction. For example, thewire transaction may be routed to respective financial institutionsassociated with the investor and broker to indicate the respectivedebit/credit to their accounts. However, substantial review and approvalprocessing may be required before a transaction may be settled. Thisprocessing may involve regulatory, security, and/or risk management.

Transaction exchange platform 210 may serve as an interface between theorigination source 205 and settlement systems 220, and according to someaspects may implement the transaction review and approval workflow foreach supported transaction type. Origination sources 205 may sendtransactions to transaction exchange platform 210 for review andapproval processing, and ultimately for routing to settlement systems220. Transaction exchange platform 210 may be provided by the sameentity operating settlement systems 220 and/or one or more oforigination sources 205, or may be provided by a third-party entity.

Transaction exchange platform 210 may perform the review and approvalprocessing for transactions. This may include interfacing with clearingsystems 215. Clearing systems 215 may provide regulatory, security,and/or risk management support for transactions. For example,transactions may be referred to systems provided by the U.S. FederalReserve as part of a clearance process. As another example, theidentities of the parties to the transaction may need to be evaluatedagainst various criteria in support of anti-money laundering or othersuch efforts. Clearing systems 215 may be provided as part oftransaction exchange platform 210, or as logically separate systems.Clearing systems 215 may be provided by the entities operatingorigination sources 205, transaction exchange platform 210, settlementsystems 220, government entities, and/or other third parties.

Transaction exchange platform 210 may interface with clearing systems215 to complete review and approval processing on the transaction.Transactions that are approved on transaction exchange platform 210 maybe routed to settlement systems 220 for settlement and/or furtherprocessing.

FIG. 3A illustrates a system 300 that may provide further details of anovel transaction exchange platform 320 than provided in FIG. 2 ,according to some aspects described herein. Similarly, transactions mayoriginate at transaction origination sources 303 and route to downstreamsettlement systems, illustrated in FIG. 3A as enterprise systems andusers 350.

Transaction exchange platform 320 may serve to perform review andapproval workflow processing on transactions received from transactionorigination sources 303 via enterprise transaction intermediary services305. Transaction origination sources 303 may include both first- andthird-party sources of transactions. The enterprise providingtransaction exchange platform 320 may provide transaction intermediaryservices 305 to receive transactions, whether from third-parties or not,and route those transactions to transaction exchange platform 320.Enterprise transaction intermediary service 305 may perform validation,pre-processing, standardization, and/or any other suitable processing toprepare transactions for further handling by transaction exchangeplatform 320.

Transactions may be sent to transaction exchange platform 320 viaapplication programming interfaces (APIs), such as API 311 and API 313.The APIs may validate aspects of the transaction details, and maypackage and/or standardize transactions into transaction objectssuitable for processing on transaction exchange platform 320. In someimplementations, transaction exchange platform 320 may provide differentAPIs for each type of transaction. For example, API 311 may correspondto ACH transactions while API 313 corresponds to wire transactions. Insome implementations, fewer APIs (such as a single centralized API) maybe used to flexibly validate and initialize transactions for processingby transaction exchange platform 320. The APIs for interfacing withtransaction exchange platform 320 may comprise a number of components,such as a public API front-end, basic input validation logic, messagelevel integrity processes, monitoring, and/or integration aspects.

Transaction objects may be pushed to a streaming data platform (SDP) 325underlying transaction exchange platform 320. Streaming data platforms,such as those based on the Apache Kafka open-source platform, may beused to process real-time data in computer systems. Message objectspushed to the streaming data platform may be read by consumer softwaremodules, processed, and put back to the streaming data platform.Transaction objects on SDP 325 may be subject to processing bymicroservices on transaction exchange platform 320, such as microservice331, microservice 332, and microservice 333. The microservices can readand write transaction objects from/to SDP 325. Objects on SDP 325 mayproceed logically through time, e.g. t₀ through t_(n), as they progressthrough stages of the workflow associated with a correspondingtransaction type.

Transaction objects, such as transaction object 307, may includetransaction details, addenda, and transaction metadata. The transactiondetails and/or addenda may include the particulars of the transaction,such as the parties and/or accounts involved, as well as the amount ofthe payment. Addenda data of the transaction object may include, e.g.,ABA routing numbers and other details that may be added, updated, and/orprocessed by the microservices on transaction exchange platform 320. Thetransaction metadata may include at least an indication of a workflowcorresponding to a transaction type of the transaction object and acurrent workflow stage of the transaction object. In someimplementations, discussed further herein, the transaction metadata mayalso include workflow version information.

As an example, transaction object 307 may include the following:

{ transaction ID : a SHA256 encoded token workflow type : ACH currentworkflow stage : init transaction details : ISO20022 token addenda data{ ABA routing : xyz } }Transaction object 307 may encapsulate any suitable standard paymentobject, such as one storing transaction details in a recognized JSONformat. As mentioned, and as illustrated further in FIG. 6 , transactionobjects may also include a current workflow version assigned to thetransaction object. Still other metadata may be included, such as areplay tracking count indicating the number of times that thetransaction has been subject to replay through one or more steps of theworkflow. Transaction details may be immutable, not subject to changewhile the transaction object is on the streaming data platform, whereasmetadata and/or addenda data may be subject to change through additions,removals, updates, and/or other processing or modification by themicroservices on transaction exchange platform 320.

A current workflow stage value may be maintained as part of thetransaction metadata in each transaction object. The current workflowstage may indicate which processing steps of the associated workflowhave been completed on the transaction. The current workflow stage mayindicate the completion status of each respective step of the workflow.As such, in an example implementation the current workflow stage valuemay be a set of values and/or a data structure indicating the completionof individual workflow steps, e.g. processing by respectivemicroservices. Microservices may be configured to poll the SDP fortransactions having a current workflow stage value that indicatescompletion of each of the pre-requisite steps for processing by themicroservice.

Microservices on the transaction exchange platform may poll the SDP toidentify and retrieve transaction objects having a current workflowstage matching a workflow stage associated with the microservice.Transaction objects matching the microservice's assigned workflow stagemay be processed by the microservice for review, approval, and/or anyother suitable processing as part of the overall series of stepsrequired to approve a transaction of the corresponding transaction type.Processing may result in updating one or more elements of thetransaction metadata. Once the microservice completes its processing ofthe transaction object, the microservice can put the transaction objectback to the SDP with an updated current workflow stage indicating thatthe microservice completed its processing. The updated transactionobject may then be identified and processed by a next microservice basedon the workflow.

Turning briefly to FIGS. 3B and 3C, FIG. 3B illustrates an examplestructure for a microservice 330N. The microservice may comprisesubcomponents configured to work in concert to apply processing logicassociated with a workflow step assigned to the microservice. In theillustrated structure, microservice 330N comprises a stream listener3301 which may operate as a standardized way to read from SDP 325 andconsume transaction objects that meet the workflow criteria (e.g.,stage) associated with microservice 330N. Microservice 330N may alsoinclude private API 3302, which may be a RESTful implementation used insynchronous calls supporting singleton integrations into transactionexchange platform 320, and its use may allow only the response to beexposed to the public API aspect of microservice 330N. Microservice 330Nmay also include core logic 3303, which may contain the business logicand associated computer instructions to fulfill microservice 330N'sassigned role in the workflow. Core logic 3303 may be adapted to processtransaction objects in accordance with one or more steps of regulatory,security, and/or risk management processes. Microservice 330N mayfurther include transient data 3304, which may include a data managementlayer that deals with data that is attributed to the local functionalityof the system, for example truth tables used in processing by core logic3303, and persistent data 3307, which may include a construct to capturestate data for the associated workflow stage. Microservice 330N mayfurther include messaging components 3305 to track message levelintegrity via natural key encryption derivations of the payment object.And microservice 330N may include monitoring components 3306, configuredto provide oversight and tracking, and integration components 3308,configured to provide the ability to integrate with software structurepatterns such as Async SDP, SOAP, RESTful API, and the like. Asillustrated in FIG. 3C, however, a microservice may be made up of acollection of other microservices. For example, as illustratedmicroservice 331N comprises component microservices 3321, 3322, and3323.

Returning to FIG. 3A, illustrative transaction exchange platform 320includes three microservices (microservices 331, 332, and 333)configured to operate on ACH transactions. Transaction object 307 is anexample ACH transaction, and is added to SDP 325 via API 311.Transaction object 307 may be added to SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice, or may be commensurate in scope with a firstworkflow stage associated with a first microservice of the workflow. Insome implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 or otherwisehandled alongside workflow processing by the respective microservices.

Walking through the example, transaction object 307 may be added to SDP325 in the initialization stage (stage ‘0’). Microservice 331 may beconfigured to perform a first step in an approval workflow fortransaction having a transaction type of ACH. For example, microservice331 may be configured to verify that the recipient account of the ACHtransaction is valid. Microservice 331 may look for transaction objectson SDP 325 having a first workflow stage (stage ‘1’), for example astage that indicates initialization pre-processing was completed or, insome implementations, transaction objects in the initialization stageitself. As mentioned above, the current workflow stage of transactionobject 307 may indicate each (and/or a subset) of the workflow stepsthat have been completed on transaction object 307, and the currentworkflow stage thus may comprise a data structure listing the completionstatus of each (and/or a subset) of the workflow steps. Microservice 331may poll SDP 325 to retrieve transaction objects having a currentworkflow stage matching (e.g., meeting) the first workflow stageassigned to microservice 331. In this manner, microservice 331 mayextract transaction objects from SDP 325 that have met the criteria formicroservice 331 to begin processing. For example, microservice 331 maybe configured to wait until initialization steps such as new objectsnapshotting is completed before performing its processing to verify therecipient account. Transaction objects retrieved by microservice 331 maybe removed and/or otherwise blocked on SDP 325 pending processing bymicroservice 331.

Microservice 331, having retrieved one or more transaction objects suchas transaction object 307, may perform its corresponding workflow stepon the transaction object. The workflow step may comprise suitableprocessing of the transaction object, such as according to core logic ofmicroservice 331 (similar to core logic 3303 of FIG. 3B). Processing ofthe transaction object by microservice 331 (or any other microservice)may comprise any of: retrieving the transaction object; reviewing valuesand other characteristics of the transaction object; interfacing withclearing systems such as clearing systems 215 and/or other systems;comparing values or characteristics to rules, regulations, policies, andthe like; adding, removing, updating, or otherwise changing any aspectof the transaction addenda data or transaction metadata; generatingreports and/or alerts; presenting the transaction for manual or otherreview; and/or any other suitable processing associated with therespective step of the workflow for transactions of that type. Forexample, processing by a microservice may comprise verifying a value ofthe transaction details, addenda data, and/or transaction metadataagainst at least one rule. As another example, processing may compriseverifying a value of the transaction details, addenda data, and/ortransaction metadata against a watchlist. Processing may comprisedetermining that the transaction details, addenda data, and/ortransaction metadata fail at least one rule; flagging the transactionobject for further review; and holding the transaction object in thecurrent workflow stage pending the further review, where updating thecurrent workflow stage of the transaction object to the third workflowstage is based on determining that the further review is completed.Flagging the transaction object for further review may comprise flaggingthe transaction object for manual review by a user and/or setting thecurrent workflow stage of the transaction object to a current workflowstage associated with another microservice, other than the microservicethat typically processes transactions after the first microservice.

The processed transaction object may be put back to SDP 325 bymicroservice 331, and the current workflow stage of the transactionobject may be updated to indicate that microservice 331 has completedits processing. For example, transaction object 307 may be updated tohave a current workflow stage of ‘2’ after microservice 331 completesits processing.

Back on the SDP 325, the updated transaction object may be subject tofurther processing by other microservices in like fashion. For example,microservice 332 may correspond to a second step of processing in theworkflow corresponding to ACH transactions, such as a regulatory checkassociated with anti-money laundering efforts. Microservice 332 may beconfigured to look for transaction objects having a second currentworkflow stage, e.g., stage ‘2’, on SDP 325. Microservice 332 can pollSDP 325 to retrieve such transaction objects and process them accordingto its own core logic, similarly to that described above with respect tomicroservice 331. The processed transaction object may be put back tothe SDP 325 with an updated current workflow stage indicating thatprocessing by microservice 332 is completed. Microservice 333 may beconfigured to look for a third current workflow stage, e.g. stage ‘3’,and may process transaction objects similarly. For example, microservice333 could perform processing to obligate a customer's account for thevalue of the transaction.

When the current workflow stage of a transaction object indicates it hascompleted the steps of the corresponding workflow, the transactionobject may be removed from SDP 325 and routed or otherwise madeavailable to other components of the overall transaction system. Forexample, the approved transaction object, having passed through allsteps of the corresponding workflow, may be published to a publicstreaming data platform 340 accessible outside of the transactionexchange platform. Enterprise systems, applications, users, and others(e.g. enterprise services and users 350) may access the completedtransaction objects on the public streaming data platform and furtherprocess for transaction settlement or other purposes.

The structure described herein, where microservices poll SDP 325 fortransaction objects having corresponding current workflow stages, maydrive payments and other transactions through the system and requisitereview and approval workflows. As mentioned, the workflow for a giventransaction type may comprise a plurality of processing steps requiredto approve a given transaction of the transaction type. Workflows may beimplemented in the configurations of what workflow stage metadata eachmicroservice is configured to look for on the SDP 325. However,workflows may also be logically described and/or defined using adirected acyclic graph structure, as described further with respect toFIG. 4 .

FIG. 4 illustrates a sample directed acyclic graph (DAG) 400 that maycorrespond to a workflow corresponding to transactions having a wiretransaction type. The steps of the workflow corresponding to a giventransaction type may be organized as a DAG. The DAG may comprise nodescorresponding to the individual steps of the workflow, and edgescorresponding to pre-requisite relationships between the steps. The DAGmay indicate how transactions from an origination source such asorigination 410 flow through the transaction exchange platform 320,until approval is completed and the transaction is ready for furtherprocessing by downstream systems. The DAG may include parallel paths,whereby the transaction object may be subject to concurrent processingby multiple microservices. The DAG may indicate pre-requisite conditionsthat govern the progression of the transaction object through the stagesof the workflow. For example, processing by a microservice in the DAGmay be conditioned on the completion of processing by one or more othermicroservices. The DAG may also indicate branching, conditional pathswhere a transaction object may be subject to processing by differentmicroservices (and/or different processing generally) based on certaintransaction attributes.

In the example workflow for wire transactions 400 illustrated in FIG. 4, a transaction object added to transaction platform 320 fromorigination 410 may first enter step ‘A’. Step ‘A’ may correspond to amicroservice that performs processing to verify that a recipient accountin the transaction details and/or addenda is valid. Once step ‘A’processing is complete, the workflow proceeds to step ‘B’, which maycorrespond to a high value thresholder that operates to splittransactions for different processing based on their value (alsoimplemented as a microservice). For example, once step ‘A’ is completedand a first microservice updates the current workflow stage of thetransaction object, a microservice associated with step ‘B’ may pick upthe transaction object and determine if it involves a payment over acertain value, e.g., payments more than 5000. The microserviceassociated with step ‘B’ may update the transaction object withdifferent current workflow stages depending on whether the transactionshould be subject to high value processing (e.g., step ‘C’) or standardprocessing (e.g., step ‘D’). Step ‘C’ may occur subsequent to step ‘B’determining that a high value transaction should be subject to enhancedverification, and may comprise performing the enhanced verification by acorresponding microservice. Step ‘D’ may comprise performing standardregulatory verification by a corresponding microservice. Step ‘D’ mayalso determine if the transaction is an international or domestic wire,and may update the current workflow stage and/or other transactionmetadata accordingly. If the transaction is an international wire, itmay be routed (by means of the updated transaction metadata) to amicroservice associated with step ‘E’, which may perform furtherinternational wire processing. If the transaction is a domestic wire, itmay proceed to step ‘F’ once regulatory checks are completed. Step ‘F’may comprise a step to obligate the customer's account for the amount ofthe wire, and may be conditioned on successful completion of steps ‘C’,‘D’, or ‘E’ depending on how the transaction progressed through theworkflow. For example, a microservice corresponding to step ‘F’ may beconfigured to poll SDP 325 for transactions having a current workflowstage that indicates they have completed steps ‘C’, ‘D’, or ‘E’.Finally, completing the workflow step ‘G’ may correspond to amicroservice configured to send the wire transaction for settlement,such as to settlement systems 220 of FIG. 2 or enterprise services andusers 350 of FIG. 3A. Having completed workflow step ‘G’, thetransaction metadata may be updated to indicate completion of theworkflow. For example, the current workflow stage of the transactionobject may be updated to indicate completion of step ‘G’. As anotherexample, the current workflow stage of the transaction object mayreflect the completion of each of steps ‘A’, ‘B’, ‘D’, ‘F’, and ‘G’.

Workflow 400 is just one example of a workflow corresponding to atransaction type, and the transaction exchange platform 320 may havemany such workflows corresponding to different transaction types.Microservices on transaction exchange platform 320 may be involved inone or more workflows, and may operate on different stages of differentworkflows.

Workflow steps may proceed in parallel, and may be independent of one ormore other steps in the workflow. For example, if validating the accountnumber of the sending party and validating the account number of thereceiving party were handled by different microservices, the workflowmay indicate that both may occur once the transaction is brought ontothe platform. However, later steps may be conditioned on the completionof both steps. Either step may occur first in time, depending on theavailability of each respective microservice to handle the transaction.

Microservices on transaction exchange platform 320 may be automaticallyconfigured to look for a corresponding current workflow stage. Thisautomatic configuration may be based on the DAG structure used tologically define the workflow. For example, the individual microservicesmay be automatically configured to poll SDP 325 for transactions havinga current workflow stage that indicates that the pre-requisite criteriarepresented in the DAG is met prior to processing by the microservice.Each microservice may be configured to look for transaction objects onSDP 325 that have a given workflow type and also have a current workflowstage matching that assigned to the microservice. Thus, microservicesmay be configured to operate as part of multiple workflows, and can lookfor transaction objects at different stages of the workflows. Asdiscussed further herein with respect to FIG. 6 , changes to the DAG maybe used to automatically re-configure the microservices to watch fortransaction objects in different workflows and/or different workflowstages.

FIG. 5 depicts a flowchart illustrating an example method 500 to processtransactions by a transaction exchange platform, such as transactionexchange platform 320. Method 500 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 500.

At step 505, the system may configure microservices on the transactionexchange platform to watch for transactions of the streaming dataplatform (SDP) that have transaction metadata indicating that they arein a current workflow stage corresponding to the individualmicroservice. As discussed above with respect to FIG. 4 , the system mayautomatically configure the microservices based on a DAG structure thatlogically defines the steps of the workflow and their relationships.

At step 510, the system may receive a transaction object and add it tothe streaming data platform. The transaction object may be received froma transaction origination source such as origination source 303, and maybe received from an enterprise intermediary service, such as enterprisetransaction intermediary service 305. The transaction object may bereceived via one or more APIs of the transaction exchange platform, suchas APIs 311 and 313 of transaction exchange platform 320. Thetransaction object may be added to the SDP in an initialization stage,which may be implemented through setting a current workflow stage of thetransaction object's transaction metadata to an initialization value.The initialization stage may be separate from a first workflow stageassociated with a first microservice of the workflow, or could be thesame as the first workflow stage. Objects in the initialization stagemay be subject to various system processes on the transaction exchangeplatform, such as format or other verifications, standardization,snapshots, and the like. If the initialization stage is separate from afirst workflow stage of the workflow, the transaction object may beupdated to have the first workflow stage once initialization processingis completed.

The transaction object, on the SDP, may be subject to processing by oneor more microservices including first microservice 520 and secondmicroservice 530. First microservice may be configured to poll the SDPfor transactions in a first workflow stage, while second microservicemay be configured to poll the SDP for transactions in a second workflowstage.

At step 521, first microservice 520 may poll the SDP for transactionshaving a particular workflow type (corresponding to a transaction type)and having a first workflow stage within that workflow corresponding tofirst microservice 520. The SDP may identify transaction objects thathave a current workflow stage value that matches the first workflowstage criteria associated with the first microservice 520.Identification of matching transaction may be based on transactionmetadata indicating a type of workflow, a current workflow stage, andother information associated with the workflow (such as workflow versioninformation, discussed below with respect to FIG. 6 ). At step 523,first microservice 520 may retrieve the matching transaction objects forprocessing. Although steps 521 and 523 are illustrated separately, itwill be understood that in practice they may be part of a singlecontiguous act.

At step 525, first microservice 520 may process the transaction objectsit retrieved from the SDP according to processing logic associated withfirst microservice 520. Processing a transaction object may include:reviewing, assessing, analyzing, updating, adding to, removing, and/orany other suitable processing of the transaction data, addenda data,and/or transaction metadata associated with the transaction object.

At step 527, first microservice 520 may update a current workflow stageof the transaction object to indicate completion of the processingcorresponding to first microservice 520. In some embodiments, thecurrent workflow stage may be updated to different next step valuesdepending on the processing by first microservice 520. For example, asdiscussed with respect to workflow 400 in FIG. 4 , a microservice mayupdate the current workflow stage of a transaction object to route it todifferent next microservices depending on whether it meets certaincriteria, such as having a value greater than a threshold amount.

At step 529, first microservice 520 may put the updated transactionobject back to the SDP. The updated transaction object may have one ormore changed values (or none) of its transaction data, addenda data,and/or transaction metadata, in addition to the updated current workflowstage.

In the example of method 500, first microservice 520 may update thecurrent workflow stage of the transaction object to indicate completionof processing by the first microservice 520. This updated currentworkflow stage may correspond to the second current workflow stage thatsecond microservice 530 is looking for on the SDP.

Thus, at step 531, the second microservice 530 may poll the SDP fortransactions having the second workflow stage and, at step 533, mayretrieve transaction objects matching the second workflow stage. Thesecond microservice 530 may perform similar processing to that describedabove with respect to first microservice 520. That is, steps 531, 533,535, 537, and 539 may be analogous to steps 521, 523, 525, 527, and 529,modified as appropriate for the role assigned to second microservice 530in the workflow for a given transaction type. The processed, updatedtransaction object may be put back to the SDP with an updated currentworkflow stage indicating completion of the processing corresponding tosecond microservice 530.

At step 540, the system may determine that the current workflow stagemetadata of the transaction object indicates that all requisiteprocessing steps of the workflow have been completed. As a result,processing by the transaction exchange platform may be completed and theapproved transaction object may be removed from the SDP and output forfurther processing and/or settlement. For example, as illustrated inFIG. 3A, a completed, approved transaction may be output to a public SDPfor access by downstream systems and users.

Thus, according to some embodiments a computer-implemented method mayreceive a transaction object comprising transaction details andtransaction metadata. That transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The computer-implemented method may furthercomprise adding the transaction object to a streaming data platform andupdating the current workflow stage of the transaction object to a firstworkflow stage. A first microservice may poll the streaming dataplatform to retrieve transactions matching the first workflow stage. Thefirst workflow stage may be associated with the first microservice basedon the workflow corresponding to the transaction type. The firstmicroservice may retrieve, from the streaming data platform, thetransaction object based on the current workflow stage matching thefirst workflow stage. The first microservice may process the transactionobject. The computer-implemented method may further comprise updatingthe current workflow stage of the transaction object to a secondworkflow stage based on completing processing, by the firstmicroservice, of the transaction object. A second microservice may pollthe streaming data platform to retrieve transactions matching the secondworkflow stage. The second workflow stage may be associated with thesecond microservice based on the workflow corresponding to thetransaction type. The second microservice may retrieve, from thestreaming data platform, the transaction object based on the currentworkflow stage matching the second workflow stage. The secondmicroservice may process the transaction object. Thecomputer-implemented method may further comprises updating the currentworkflow stage of the transaction object to a third workflow stage basedon completing processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the plurality ofprocessing steps. A different second workflow may be associated with asecond transaction type and may comprise a different second plurality ofprocessing steps required to approve a given transaction of the secondtransaction type. The second transaction type may be different from thetransaction type. The first microservice may operate on transactionsassociated with both the workflow and the different second workflow. Theplurality of processing steps of the workflow may indicate that thefirst microservice processes the transaction object at a different stagethan the different second plurality of processing steps of the differentsecond workflow.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the DAG. Thecomputer-implemented method may further comprise, responsive to anupdate to at least one of the plurality of processing steps indicated inthe DAG, automatically reconfiguring at least one microservice based onthe update.

The current workflow stage of the transaction object may comprise a datastructure indicating completion status of each respective step of aplurality of processing steps associated with the workflow. Thetransaction object may be updated to have a current workflow stagecorresponding to the second workflow stage based on the current workflowstage indicating that the transaction object has been processed by atleast the first microservice and a different third microservice. Thefirst workflow stage and a fourth workflow stage may be independent,such that a third microservice receives the transaction object based onthe current workflow stage of the transaction object matching the fourthworkflow stage irrespective of whether the first microservice hasprocessed the transaction object.

The transaction details may be immutable and may not change while thetransaction object is on the streaming data platform. The processing, bythe first microservice, of the transaction object may comprise verifyinga value of the transaction details, addenda data, and/or transactionmetadata against at least one rule. Processing of the transaction objectby the first microservice may comprise verifying a value of thetransaction details, addenda data, and/or transaction metadata against awatchlist. Processing of the transaction object by the secondmicroservice may comprise determining that the transaction details,addenda data, and/or transaction metadata fail at least one rule,flagging the transaction object for further review, and holding thetransaction object in the second workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object tothe third workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisesetting the current workflow stage of the transaction object to a fourthworkflow stage associated with a third microservice. Updating thecurrent workflow stage of the transaction object to the third workflowstage may be based on determining that processing by the thirdmicroservice is completed.

As examples, the transaction type of the transaction object may be awire type transaction. The workflow may comprise a plurality ofprocessing steps required to approve a wire transaction. The transactiontype of the transaction object may be an automated clearing house (ACH)type transaction. The workflow may comprise a plurality of processingsteps required to approve an ACH transaction. The transaction type ofthe transaction object may be a cashier check type transaction. Theworkflow may comprise a plurality of processing steps required toapprove a cashier check transaction. The first microservice may processthe transaction object to validate a routing number associated with thetransaction object. The second microservice may process the transactionobject to verify compliance with at least one regulatory requirementassociated with the transaction type. The transaction object may bereceived via an application programming interface (API).

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice and a second microservice. The first andsecond microservice may be automatically configured to watch fortransactions on the streaming data platform in corresponding workflowstages based on a plurality of workflows corresponding to a plurality oftransaction types. The memory may store instructions that, when executedby the at least one processor, cause the platform to receive atransaction object comprising transaction details and transactionmetadata. The transaction metadata may comprise an indication of aworkflow corresponding to a transaction type of the transaction objectand a current workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The instructions, when executed by the at least oneprocessor, may further cause the platform to add the transaction objectto the streaming data platform; update the current workflow stage of thetransaction object to a first workflow stage; and poll, by the firstmicroservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The instructions, when executedby the at least one processor, may further cause the platform toretrieve, by the first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; process, by the first microservice,the transaction object to add, remove, or update addenda data associatedwith the transaction object; update the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; andpoll, by the second microservice, the streaming data platform toretrieve transactions matching the second workflow stage. The secondworkflow stage may be associated with the second microservice based onthe workflow corresponding to the transaction type. The instructions,when executed by the at least one processor, may further cause theplatform to retrieve, by the second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage; process, by the secondmicroservice, the transaction object; update the current workflow stageof the transaction object to a third workflow stage based on completingprocessing, by the second microservice, of the transaction object;determine that the current workflow stage of the transaction objectindicates that the transaction object has completed processingcorresponding to the workflow; and remove the transaction object fromthe streaming data platform and output the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; updating the currentworkflow stage of the transaction object to a first workflow stage; andpolling, by a first microservice, the streaming data platform toretrieve transactions matching the first workflow stage. The firstworkflow stage may be associated with the first microservice based onthe workflow corresponding to the transaction type. The steps mayfurther comprise retrieving, by the first microservice and from thestreaming data platform, the transaction object based on the currentworkflow stage matching the first workflow stage; processing, by thefirst microservice, the transaction object; and polling, by a secondmicroservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may be alsoassociated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the second microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; processing, by the secondmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice and the secondmicroservice, of the transaction object; and polling, by a thirdmicroservice, the streaming data platform to retrieve transactionsmatching the second workflow stage. The second workflow stage may beassociated with the third microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the third microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the second workflow stage; processing, by the thirdmicroservice, the transaction object; updating the current workflowstage of the transaction object to a third workflow stage based oncompleting processing, by the third microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; and retrieving, by a second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage. The second workflow stage maybe associated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the second microservice, the transaction object; updatingthe current workflow stage of the transaction object to a third workflowstage based on completing processing, by the second microservice, of thetransaction object; determining that the current workflow stage of thetransaction object indicates that the transaction object has completedprocessing corresponding to the workflow; and removing the transactionobject from the streaming data platform and outputting the transactionobject and an indication that the transaction object has completed theprocessing corresponding to the workflow.

Configurator—Dynamic Microservice Configuration

One or more aspects described herein may provide for dynamicreconfiguration of the workflows and/or microservices. For example, aworkflow may be modified to change a progression of a transaction objectfrom one microservice to the next. This may be implemented by modifyingthe configuration of a microservice to look for a different currentworkflow stage on the streaming data platform. A microservice may bemodified to change processing logic and/or any other aspect controllinghow the microservice interacts with the streaming data platform and/ortransaction objects, or any other aspect of the microservice. Forexample, processing logic of the microservice may be changed to anupdated version to be used in processing future transactions.

A configuration interface may generate configuration transaction objectsthat cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. The configurationtransaction objects may operate such that a target microservice isreconfigured as a result of processing the configuration transactionobject, whether to look for transactions on a different workflow and/orworkflow stage, or to modify the processing logic applied to thetransactions retrieved by the microservice.

As discussed above, each defined workflow on transaction exchangeplatform 320 may accept a transaction as part of the transaction's“saga” through the transaction exchange platform. Through the workflow,the transaction may or may not undergo different processing steps, whereeach step may be provided by one or many microservices or vendorsystems. In this way, updating the “saga” that applies to themicroservices, integrated vendor systems and datasets, and the entiretransaction exchange ecosystem may be akin to an exercise inconfiguration control. Aspects described herein may allow configurationsto be loaded into the transaction exchange platform via the streamingdata platform, and may be used to update the entire transaction exchangeplatform, one or more components of the transaction exchange platform,and/or transactions on the platform.

Traditional methods for doing this may require that each element of theworkflow be updated, creating exponentially expanding complexity,downtime, and consequently interjecting risk to the transaction exchangeecosystem. Dynamic reconfiguration as described further herein may solvea problem of traditional deployments that interrupt the entire systemand require each component to be individually validated. It may alsointerject a level of control in the deployment by enabling any level ofcontrol from the level of remapping the system up to controlling whichcomponent gets transactions associated with different versions of thecorresponding workflow. Dynamic reconfiguration may also provide controlover the system so that configuration can work from the most tacticalsingle transaction (singleton) level up to the entire transactionexchange. Coupled with other tools, such as cloud-based resiliencytools, dynamic reconfiguration may provide a level of flexibility notpresent in other deployment approaches or solutions to simplifyingand/or mitigating the risk of a failed deployment.

The transaction exchange may exist in a space that includes numerouslegacy, vendor, and future state solutions. Dynamic reconfiguration mayprovide advantages in supporting partnering with vendors and thirdparties of any kind as an integration approach can be agreed on andbrought into the transaction exchange as a service controlled throughdynamic reconfiguration. Once integrated, similarly to the versioncontrol described herein, the integration service can be toggled on andoff easily through dynamic reconfiguration processes.

FIG. 6 illustrates a transaction processing system 600, similar to thatillustrated in FIG. 3A and sharing many like components. However,transaction processing system 600 includes configuration interface 660to provide dynamic reconfiguration of the workflows and/ormicroservices. Configuration interface 660 may push configurationtransaction objects to SDP 325 to cause re-configuration of a firstmicroservice 631 a (represented as first version 631 a, which may beupdated to second version 631 b). Due to dynamic reconfiguration,transaction objects may be modified to keep track of the workflowversion they should be processed under, as shown by example transactionobject 607.

Users managing transaction exchange platform 320 may determine todynamically reconfigure one or more aspects of the platform, such as bymodifying a workflow or causing a new version of a microservice to bedeployed. Reconfiguration may be prompted through other processes, suchas via a watchdog microservice as discussed further below with respectto FIG. 9 . Reconfiguration may be done to update and/or improvesoftware processes. Reconfiguration may also be done to address problemsthat arise during processing, such as when certain systems becomeunavailable or otherwise encounter problems. Reconfiguration may be doneas a new persistent configuration, or could be temporary pendingresolution of an issue. The reconfiguration may target any aspect of theplatform with desired granularity. For example, the reconfiguration mayapply to the entire platform, one or more microservices, and/or one ormore transactions, as appropriate. Workflows on transaction exchangeplatform 320 may also be reconfigured, which may be accomplished throughmodifying individual microservices to control the workflow type andworkflow stages that they watch for.

Configuration interface 660 may generate configuration transactionobjects that cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. Each microservice ontransaction exchange platform 320 may be configured to watch fortransaction objects having a configuration workflow type (e.g.,configuration transaction objects), and may have a correspondingworkflow stage similarly to that discussed above with respect to FIGS.3A and 4 .

A configuration transaction object may be configured such that, whenprocessed by a microservice, it causes reconfiguration of thatmicroservice. Microservices on the transaction exchange platform 320 maybe programmed to process configuration transaction objects and makesuitable changes to their parameters based on the processed objects. Forexample, a microservice may process configuration transaction objectcomprising instructions to update the workflow assigned to themicroservice to a second version of the workflow, e.g., ACH v. 2, andmay update a workflow stage assigned to the microservice.Reconfiguration of microservices can be used to update workflows to newversions, create new workflows, and/or modify existing workflows.Transactions requiring modified processing may be assigned tomodified/updated/other workflows to change their assigned processing.

Versioning may be used to control processing by appropriate workflows,and may facilitate reliable and accurate record keeping and playback. Bytracking which version of a workflow handles a transaction, thetransaction can be replayed using the same version at a later time aspart of an audit. To this end, microservices may maintain separateindications of each workflow and version handled by the microservice.Transactions may maintain transaction metadata indicating a versionvalue for the workflow applied to the transaction. Transactions may beassigned a current workflow value when added to the transaction exchangeplatform, and this may be maintained through the life of thetransaction. In some circumstances, the version may be changed later andthe transaction re-run through the new version of the workflow.

Examples of some types of changes that may be implemented throughdynamic reconfiguration will be discussed with references to FIGS.7A-7C.

FIG. 7A illustrates pushing a new configuration to one or more of themicroservices associated with example workflow 710, which may correspondto example wire transaction workflow 400. This new configuration maymodify the processing logic applied by one or more of the microservicescorresponding to the steps of workflow 400/710. Configuration interface660 may generate a configuration transaction object comprising the newconfiguration and push it to the SDP stream. The configurationtransaction object may cause update of the microservices mid-stream aspart of the flow within the transaction exchange platform on the SDP.Each microservice, as with transaction objects, may be configured towatch for configuration transaction objects associated with aconfiguration workflow and corresponding workflow stage. Themicroservices may retrieve matching configuration transaction objectsand process them to effect an update to their respective processinglogic. A microservice, transaction object, and/or the configurationmicroservice may maintain a new and prior version of theirconfigurations. This may allow for processing under an appropriateversion, and may facilitate a transition between versions as furtherdiscussed herein.

The mid-stream nature of the dynamic reconfiguration may help avoidsignificant interruptions and replayability problems posed by priorsolutions. As illustrated, transactions 20, 30, 31, 32, and 33 may be onthe SDP and already subject to processing by microservices in thecurrent version of the workflow. When a new configuration is pushed(such as version 6.0), the transactions pending on the SDP may continueto be processed according to the prior version that they started under(e.g., version 5.0). New transactions 34, 35, 36, and 37 may beprocessed under the new version (6.0). As described above, this may beeffected through transaction metadata tracking the workflow versionassociated with the transaction as well as by configuring themicroservices to utilize version metadata in retrieving transactionsfrom the SDP. For example, returning to FIG. 6 , microservice 631 a mayrepresent a first version of a microservice that looks for transactionsin a given workflow type that have a first version value at acorresponding first workflow stage. Microservice 631 b may represent asecond version of the microservice, and may look for transactions in thesame workflow type but having a second version value at the samecorresponding first workflow stage. In some implementations, the versionvalue may be combined with the workflow type rather than separate (e.g.,“ACHv1” and “ACHv2” as separate workflows rather than version values).

This procedure, pushing configuration transaction objects via the SDP,may provide additional advantages in that, when new components areadded, the configuration interface 660 can interject that new componentmid-stream so that it is enabled as a new route without updating theentire transaction exchange. This limits disruption to the local “new”component being added or changed while protecting the entire system forthe change. This may be advantageous as change remains one of the singlebiggest drivers of break events. It also enables on-the-fly updateswithout taking the entire system down into maintenance.

FIG. 7B illustrates a dynamic reconfiguration of a workflow process 720,such as when a component becomes unavailable due to breakage or otheradverse events. The dynamic reconfiguration may reconfigure the workflowto bypass problematic services and redirect the workflow to manualreview and/or other replacement processing steps. The reconfigurationmay avoid bottlenecks associated with microservices earlier in theworkflow breaking and preventing transactions from advancing to latermicroservices. Reconfiguration of workflows may be accomplished throughreconfiguring the microservices involved in the workflow to look fordifferent current workflow stages on the SDP.

For example, in reconfigured workflow process 720, which may be amodification of example wire transaction workflow 400, the dynamicreconfiguration may cause all wire transactions to be subject to theenhanced processing of step ‘C’ rather than the branching pathsdescribed above with respect to FIG. 4 . This may be due to enhancedsecurity concerns, problems with international wire processing, problemsat other components, etc. The reconfiguration of FIG. 7B may beaccomplished by configuration interface 660 pushing a configurationtransaction object to the SDP that is configured to cause themicroservices associated with workflow 400/720 to modify what workflowsand workflow stages they look for, as well as how they update thecurrent workflow once processing is completed. In particular, themodification shown in FIG. 7B could be effected by modifying themicroservice associated with step ‘D’ to not pull any transactions,while the microservice affiliated with step ‘C’ may pull alltransactions completed by step ‘B’; or step ‘B’ could be modified toupdate the current workflow of all processed transactions such that theyprogress to the enhanced verification of step ‘C’, for example.

Modifications to the workflow may be done in response to determiningconditions that indicate that modified workflow processing should beimplemented. The modifications may also be done in response to userchanges to a DAG representing the workflow. A user may modify the DAG todefine a new workflow/version and the configuration interface 660 maygenerate a suitable configuration transaction object and push it to theSDP to effect the change. The system may provide a graphical userinterface to facilitate users entering modifications to the DAGassociated with the workflow processing.

Reconfiguration of the workflows and/or microservices may be handled ina versioned manner, such that transactions on the SDP may be handledaccording to an appropriate and auditable version of the workflow. Whena new configuration version is pushed to the SDP for a given workflow,it may be added with a new version value. Transaction objects on thetransaction exchange platform may include, as part of their transactionmetadata, an indication of a current version value for the workflow atthe time they entered the transaction exchange platform. Themicroservices on the transaction exchange platform may be furtherconfigured to identify transaction objects having an appropriate currentworkflow stages based on the version value of the transaction object.Thus, transactions added under a first workflow version may reliably beprocessed under the first workflow version, while transaction addedafter a shift to a second workflow version may be processed using thenew, updated workflow version (and associated microservices andprocessing logic).

Thus, a first microservice in a first version 631 a may be originallyconfigured to watch for transactions associated with the first workflowthat have a first version value, while the first microservice in asecond version 631 b may be configured to watch for transactionsassociated with the first workflow that have a different second versionvalue. Transactions added to the transaction exchange platform may beadded having a first version value prior to reconfiguring the firstmicroservice. The first version of the first microservice 631 a mayretrieve transactions matching the first version value in acorresponding workflow/stage. Once a reconfiguration is pushed to theSDP, later transaction added to the SDP may be added having a secondversion value. The second version of the first microservice 631 b mayretrieve transaction matching the second version value in acorresponding workflow/stage. This may allow for reliable and replayableprocessing of transactions according to the appropriate version ofapproval workflows.

New workflow versions may be added as illustrated in FIG. 7C, throughworkflow 730. One flexible use of this approach is the ability togenerate a workflow designed to modify an individual transaction and/orgroup of transactions. Version 1 of the work flow, indicated by thesingle arrows, may be applied to general transaction objects of a giventransaction type. Version 2 of the workflow, indicated by the doublearrows, may be applied to problematic transactions subject to modifiedprocessing. The transaction exchange platform may support microservices,queuing, and manual workflows as part of being highly resilient,especially around high value workflows. As such, the dynamicconfiguration aspects may facilitate controlling a single transaction'spath through the platform enabling it to bypass steps normally requiredby the common workflow. A new workflow can be introduced to theecosystem with differentiating execution tied directly to a transaction.

As an example implementation, the following sample data illustrates howa workflow may change across versions of the workflow according to oneor more aspects:

Initial Configuration Version 1 { “SecurityIdentifier”: “<<identifier >>”, “ConfigurationVersion”: “1”, “WorkflowStage”: [{ “A”: [{“WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],“WorkflowStageCompleted”: [“INIT”] }], “B”: [{ “WorkflowType”: [“WIRE”,“ACH”, “RTP”, “CHECK”, “CONFIG”], “WorkflowStageCompleted”: [“A”] }],“C”: [{ “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],“WorkflowStageCompleted”: [“B”] }], “E”: [{ “WorkflowType”: [“WIRE”,“ACH”, “RTP”, “CHECK”, “CONFIG”], “WorkflowStageCompleted”: [“B”] }],“F”: [{ “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],“WorkflowStageCompleted”: [“C”, “E”] }], “G”: [{ “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”], “WorkflowStageCompleted”:[“F”] }] }] } Post Configuration Update Version 2 {“SecurityIdentifier”: “<< identifier >>”, “ConfigurationVersion”: “2”,“WorkflowStage”: [{ “A”: [{ “WorkflowType”: [“WIRE”, “ACH”, “RTP”,“CHECK”, “CONFIG”], “WorkflowStageCompleted”: [“INIT”] “B”: [{“WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],“WorkflowStageCompleted”: [“A”] }], “D”: [{ “WorkflowType”: [“WIRE”,“ACH”, “RTP”, “CHECK”, “CONFIG”], “WorkflowStageCompleted”: [“B”] }],“C”: [{ “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],“WorkflowStageCompleted”: [“D”] }], “F”: [{ “WorkflowType”: [“WIRE”,“ACH”, “RTP”, “CHECK”, “CONFIG”], “WorkflowStageCompleted”: [“C”] }];“G”: [{ “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],“WorkflowStageCompleted”: [“F”] }] }] }

Another aspect of dynamic reconfiguration may provide an eventconfiguration library. Configurations employed to process transactionshave certain characteristics may be stored for re-use in other settings,such as when those same characteristics are encountered again.Configurations that were pushed to resolve those transaction may be usedagain to facilitate handling of other similar transactions. For example,if manual or other review identifies a high risk transaction, a highrisk transaction configuration can be pushed to apply a high riskversion of the workflow to the high risk transaction. As a particularexample, consider when a transaction is associated with a merger of twocompanies. To facilitate the merger, transactions may be reconfigured tobypass standard workflows and feed through specialized microservicesconfigured to meet specific reporting needs of M&A transactions.

These configurations may be utilized manually, automatically, through ahybrid approach, and others. For example, machine learning may beemployed to recognize problem situations with transactions. The machinelearning system may flag a transaction to be reconfigured to follow aconfiguration of the configuration library that was previously employedon similar transactions. The system may be designed to self-optimize itsown configurations, employing approaches based on features such asshortest path, fastest time, most secure, guaranteed deliver, or anyother features desirable to customers.

FIG. 8 depicts a flowchart illustrating an example method 800 todynamically reconfigure a transaction exchange platform, such astransaction exchange platform 320. Method 800 may be performed by anysuitable computing device and/or combination of computing devices,referred to as the system implementing method 800.

At step 805, the configuration interface 660 may generate aconfiguration transaction object. The configuration transaction objectmay be configured to cause a reconfiguration of the transaction exchangeplatform, one or more workflows, one or more microservices, and/or oneor more transactions. The configuration interface 660 may receive arequest to generate the configuration transaction object from a userand/or other system processes, such as a watchdog microservice(discussed further below with respect to FIG. 9 ). The configurationtransaction object may comprise transaction details and transactionmetadata. The transaction metadata may indicate that the transactionobject has a configuration workflow type and a current workflow stage ofthe configuration transaction object. In some embodiments, the workflowtype of the configuration transaction object is a workflow that ismodified by the configuration transaction object, and other aspects ofthe configuration transaction object indicate to a processingmicroservice that it includes an update to the processing of themicroservice. The configuration transaction object may includeinstructions that, when processed by the microservice, cause themicroservice to be reconfigured. Reconfiguration may include modifyingwhich workflow/version/stage the microservice looks for on the SDP,and/or may include modifying the core processing logic employed by themicroservice.

At step 810, the configuration interface 660 may add the configurationtransaction object to the SDP, where it may await processing by firstmicroservice 820 and second microservice 830.

The configuration transaction object may be picked up by firstmicroservice 820 and second microservice 830 in a similar fashion tothat described above with respect to FIG. 5 . At steps 821 and 831,first and second microservices 820 and 830 may poll the SDP to retrievetransactions matching their assigned workflow stages in correspondingworkflow types. The configuration transaction objects may have aconfiguration workflow type, and the microservices may watch for aconfiguration workflow type object having the workflow stagecorresponding to the microservice. At steps 823 and 833, themicroservices may retrieve the configuration transaction object forprocessing.

At steps 825 and 835, the microservices may process the configurationtransaction object when it is in a corresponding workflow stage.Processing the configuration transaction object may cause themicroservice to be updated. For example, the configuration transactionobject may cause the microservice to update what workflow/version/stageit looks for on the SDP. As another example, processing theconfiguration transaction object may cause the microservice to updatethe core processing logic that it applies to transactions.

At steps 827 and 837, the microservices may update the current workflowstage of the configuration transaction object and, at steps 829 and 839,the microservices may push the updated configuration object back to theSDP. For example, microservice 820 may update the current workflow stageof the configuration object to indicate that microservice 820 hascompleted processing, and microservice 830 may be configured to look fortransaction objects that have a current workflow stage that indicatesthat microservice 820 completed its processing.

At step 840, the system may determine that the current workflow stage ofthe configuration transaction object indicates that the processingassociated with the configuration workflow has completed, and theconfiguration transaction object may be removed from the SDP.Notification may be provided to an entity that prompted thereconfiguration that it has been implemented, in some embodiments.

Thus, according to some aspects, a computer-implemented method maycomprise configuring a plurality of microservices on a streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and may comprise a plurality of processing stepsrequired to approve a given transaction of the transaction type. Thesteps may further comprise generating a configuration transaction objectthat may be configured to cause reconfiguration of the first workflow bycausing reconfiguration of at least one microservice of the plurality ofmicroservices. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow and acurrent workflow stage of the configuration transaction object. Thesteps may further comprise adding the configuration transaction objectto the streaming data platform and updating the current workflow stageof the configuration transaction object to a first workflow stage. Themethod may comprise polling, by a first microservice of the plurality ofmicroservices, the streaming data platform to retrieve transactionsmatching the first workflow stage; retrieving, by the first microserviceand from the streaming data platform, the configuration transactionobject based on the current workflow stage matching the first workflowstage; processing, by the first microservice, the configurationtransaction object to reconfigure the first microservice; and updatingthe current workflow stage of the configuration transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the configuration transaction object. The method mayalso comprise determining that the current workflow stage of theconfiguration transaction object indicates that the configurationtransaction object has completed processing corresponding to theconfiguration workflow, and removing the configuration transactionobject from the streaming data platform and outputting an indicationthat the configuration transaction object has completed the processingcorresponding to the configuration workflow.

Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to watch for a different second workflow stage.Reconfiguring the first microservice may cause the first microservice toprocess transaction objects at a different stage of the plurality ofprocessing steps of the first workflow. Reconfiguring the firstmicroservice may comprise reconfiguring the first microservice to modifyat least one operation that the first microservice performs ontransaction objects associated with the first workflow. Reconfiguringthe first microservice may cause removal of at least one secondmicroservice from the first workflow. The first microservice may beoriginally configured to update completed transactions with a firstcompleted workflow stage. Reconfiguring the first microservice maycomprise reconfiguring the first microservice to update completedtransactions with a different completed workflow stage. Reconfiguringthe first microservice may cause transaction objects to bypass at leastone second microservice included in the first workflow. The firstmicroservice may be originally configured to watch for transactionsassociated with the first workflow that have a first version value. Thereconfigured first microservice may be configured to watch fortransactions associated with the first workflow that have a differentsecond version value.

The method may further comprise adding a first transaction object havinga first version value to the streaming data platform prior toreconfiguring the first microservice; retrieving, by the firstmicroservice and from the streaming data platform, the first transactionobject based on a current workflow stage of the first transactionmatching the first workflow stage; processing, by the firstmicroservice, the first transaction object based on an originalconfiguration of the first microservice based on the first versionvalue; adding a second transaction object having a different secondversion value to the streaming data platform subsequent to reconfiguringthe first microservice; retrieving, by the first microservice and fromthe streaming data platform, the second transaction object based on acurrent workflow stage of the second transaction matching the firstworkflow stage; and processing, by the first microservice, the secondtransaction object based on the reconfiguration of the firstmicroservice based on the second version value. The steps may furthercomprise adding a first transaction object to the streaming dataplatform; determining a current version of the first workflowimplemented on the streaming data platform; and updating a version valueof the first transaction object based on the current version. The firstmicroservice may process the first transaction object based on anoriginal configuration or a modified configuration based on the versionvalue.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first microservice may be automatically configured to watch fortransactions on the streaming data platform in the first workflow stagebased on the DAG. Generating the configuration transaction object may bein response to an update to at least one of the plurality of processingsteps indicated in the DAG. The steps may further comprise providing agraphical user interface to allow a user to update the at least one ofthe plurality of processing steps indicated in the DAG.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be automatically configured to watch for transactionson the streaming data platform in a corresponding workflow stage basedon a plurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingconfiguring the plurality of microservices on the streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and comprises a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise processing, by a first microservice, transactionobjects on the streaming data platform based on the configuration; andgenerating a configuration transaction object that may be configured tocause reconfiguration of the first workflow by causing reconfigurationof at least one of microservice of the plurality of microservices. Theconfiguration transaction object may comprise transaction metadata thatindicates a configuration workflow and a current workflow stage of theconfiguration transaction object. The steps may further comprise addingthe configuration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to a first workflow stage; polling, by a first microservice ofthe plurality of microservices, the streaming data platform to retrievetransactions matching the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Subsequent to processing the configuration transaction object, the firstmicroservice may process transaction objects on the streaming dataplatform based on the reconfiguration.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise configuring a first microservice on a streaming dataplatform to watch for transactions having a first workflow stageassociated with a first workflow corresponding to a transaction type.The first workflow may comprise a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise configuring a second microservice on the streaming dataplatform to watch for transactions having a second workflow stageassociated with the first workflow; and generating a configurationtransaction object that may be configured to cause reconfiguration ofthe first workflow by causing reconfiguration of the first microserviceand the second microservice. The configuration transaction object maycomprise transaction metadata that indicates a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; updating the current workflowstage of the configuration transaction object to the first workflowstage; polling, by the first microservice, the streaming data platformto retrieve transactions matching the first workflow stage; retrieving,by the first microservice and from the streaming data platform, theconfiguration transaction object based on the current workflow stagematching the first workflow stage; processing, by the firstmicroservice, the configuration transaction object to reconfigure thefirst microservice; updating the current workflow stage of theconfiguration transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the configurationtransaction object; polling, by the second microservice, the streamingdata platform to retrieve transactions matching the second workflowstage; retrieving, by the second microservice and from the streamingdata platform, the configuration transaction object based on the currentworkflow stage matching the second workflow stage; processing, by thesecond microservice, the configuration transaction object to reconfigurethe second microservice; updating the current workflow stage of theconfiguration transaction object to a third workflow stage based oncompleting processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the configurationtransaction object indicates that the configuration transaction objecthas completed processing corresponding to the configuration workflow;and removing the configuration transaction object from the streamingdata platform and outputting an indication that the configurationtransaction object has completed the processing corresponding to theconfiguration workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising configuring a plurality of microservices on a streamingdata platform to watch for transactions having a corresponding workflowstage associated with a first workflow. The first workflow maycorrespond to a transaction type and comprises a plurality of processingsteps required to approve a given transaction of the transaction type.The steps may further comprise generating a configuration transactionobject that may be configured to cause reconfiguration of the firstworkflow by causing reconfiguration of at least one microservice of theplurality of microservices. The configuration transaction object maycomprise transaction metadata that indicates: a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; retrieving, by a firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching a firstworkflow stage associated with the first microservice; processing, bythe first microservice, the configuration transaction object toreconfigure the first microservice; and updating the current workflowstage of the configuration transaction object to a second workflow stagebased on completing processing, by the first microservice, of theconfiguration transaction object.

Chronos—Snapshot Microservice and Transaction Replay

Some aspects described herein may provide a snapshot microservice on thetransaction exchange platform, configured to maintain a record of thedata values of each transaction object as they progress through thecorresponding workflows. “Snapshot,” when used to refer to the snapshotmicroservice, may refer to the functionality of the snapshotmicroservice to track a transaction object's data values and each of itschanged states as an archival service. The snapshot microservice thusmay also be referred to as a payment transaction object changed statearchive, or Chronos. The snapshot microservice may create a snapshotrecord for new transaction objects and store a copy of the data of thetransaction object. As the transaction object progresses through theworkflow and is processed by the other microservices, the snapshotmicroservice can identify transaction objects that have their datachanged. The snapshot microservice can retrieve the changed objects andstore snapshot data tracking the change of the transaction object.

FIG. 9 illustrates a transaction processing system 900 that may besimilar to transaction processing systems 300 and/or 600 of FIGS. 3A and6 . Transaction processing system 900 may add, relative to systems 300and 600, snapshot microservice 970 and watchdog microservice 980. Thisdocument section focuses on snapshot microservice 970, while the nextdocument section focuses on watchdog microservice 980.

Snapshot microservice 970 may operate on transaction exchange platform320 to maintain a record of the data values of each transaction objecton the streaming data platform, and may track how the transactionobjects change during processing on the platform. Snapshot data may bestored in snapshot database 975, which may comprise on-disk storagecapable of effectively storing large volumes of data. Snapshotmicroservice 970 and snapshot database 975 may be configured to storedifferential snapshots of a transaction object. Snapshot microservice970 may store an original state of a transaction object when it is addedto the SDP, and may store information indicating each subsequent changeto the transaction object. Snapshot microservice may track data valuesassociated with each of the transaction details, transaction addendadata, and/or transaction metadata. In some embodiments however, thetransaction metadata may be additionally and/or alternatively tracked bywatchdog microservice 980.

The snapshot microservice 970 may be configured to identify and retrievetransaction objects added to SDP 325 in an initialization stage.Transaction objects may be added to the SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice 331, or may be commensurate in scope with a firstworkflow stage associated with a first microservice 331 of the workflow.In some implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 that receivetransactions to be added to the SDP 325, or otherwise handled alongsideworkflow processing by the respective microservices 331, 332, and 333.

Snapshot microservice 970 may store an initial snapshot of a transactionobject in the initialization stage, then update a current workflow stageof the transaction object to indicate that the initialization processinghas completed. This may comprise updating the current workflow stage ofthe transaction object to match a first workflow stage associated withmicroservice 331, which microservice 331 performs the first step of theworkflow. Alternatively, snapshot microservice 970 may treat transactionobjects in the first workflow stage as being subject to initialization(as new objects), and may determine that an initial, new snapshot shouldbe recorded in snapshot database 975.

Snapshot microservice 970 may be configured to poll the SDP to retrieveall transaction objects having changed data. In some embodiments, thismay comprise retrieving all transaction objects and determining whetherthere have been any changes. In other embodiments, it may compriseretrieving specifically the transaction objects that have changed,whether based on determining that the data has changed or merely that aworkflow stage has advanced. Snapshot microservice 970 may determine adifference in the changed transaction object and store snapshotinformation indicating the difference. The snapshot information mayinclude metadata such as an associated timestamp, workflow stage, and/orany other suitable metadata to facilitate audit and potential rollbackof the transaction object and workflow processing.

These snapshots of the transaction object may be used to correctprocessing errors in the approval workflow, as a transaction object mayhave its data reverted back to an earlier state and its workflow stagereverted to an earlier stage. In this way, the transaction object may bemade to repeat an earlier step of the workflow and be subject tore-processing by a corresponding microservice (or, in some cases such asrepeated failures, a human operator). The snapshot microservice 970 mayregenerate a transaction object using the snapshot data corresponding tothe transaction object from an earlier time, prior to a point inprocessing that is subject to the rewind. In effect, snapshotmicroservice 970 may roll back the values of the transaction object toan earlier point in time. Then, the regenerated transaction object maybe put back on SDP 325 and will be picked up for re-processing by theearlier microservice. For example, if an error is determined to haveoccurred during processing of transaction object 307 by firstmicroservice 331, the snapshot microservice 970 may revert transactionobject 307 to state prior to processing by first microservice 331. Thefirst microservice 331 would have updated the stage of the transactionobject 307 to the second workflow stage when processing completed. Thesnapshot microservice 970 may revert the current workflow stage of thetransaction object 307 to the first workflow stage, so that when thetransaction object 307 is pushed back to the SDP 325 it will be pickedup for processing again by the first microservice 331.

A command to replay a transaction may be received by the snapshotmicroservice 970. For example, watchdog microservice 980 may determinethat processing by first microservice 331 completed abnormally, and maycommand snapshot microservice 970 to perform a replay. Other conditionsmay prompt a replay, such as an error state of a microservice or thetransaction exchange platform 320.

The snapshot microservice may track the total number of times that atransaction object is reverted/replayed on one or more microservices,and may flag a transaction as presenting problems requiring manual orother review when the number of replays exceeds a transaction or basedon other criteria. Replaying a transaction may cause update of atransaction replay count associated with the transaction, which may bestored as part of the transaction object's transaction metadata and/oras part of the snapshot information. If a threshold number of replaystake place, for example a configurable maximum of 3 replays at a singlestage of the workflow, the snapshot microservice 970 may flag thetransaction as having failed and/or requiring further review. Themaximum, which may be implemented as a threshold value, may beconfigured by a user and/or may be automatically configured by systemprocesses based on historical data, current system state, and otherperformance metrics. The transaction may be held in a workflow stagecorresponding to the microservice where processing failed, in someinstance. In other instances, a failed transaction may be routed toadditional processing, such as by a different workflow and/or otherparts of the same workflow, where it may be processed by othermicroservices.

When a replay occurs, the snapshot information may continue to track allsubsequent events as well as all events that had occurred already on thetransaction, even if they are subject to rewinding. Thus, the snapshotinformation may support a comparison during troubleshooting to assesswhich parts of the system led to errors in the workflow. Thisinformation may be archived to assist in troubleshooting and audits.Snapshot information related to error processing that is fixed viareplay may be deleted upon successful completion of the re-attempt.

The snapshot data may also support audit of the transactions, offering acomplete picture of how the transaction object changed while on thetransaction exchange platform. If desired as part of auditing results,the snapshot microservice 970 may replay an entire transaction snapshotby snapshot. This may be done in support of an audit or fortroubleshooting and analysis.

FIG. 10 depicts a flowchart illustrating an example method 1000 togenerate snapshot information tracking a transaction object on atransaction exchange platform, such as transaction exchange platform320. Method 1000 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1000.

At step 1005, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1031, snapshot microservice 1030 may store an initial snapshotrecord for new transaction objects on the SDP. For example, snapshotmicroservice 1030 may poll the SDP for transaction objects in theinitialization stage. Alternatively and/or additionally, snapshotmicroservice 1030 may poll SDP for all transaction objects, anddetermine which are new and should be stored as initial snapshotrecords.

At step 1033, snapshot microservice 1030 may update the current workflowstage of the transaction object to indicate completion of initializationprocessing by the snapshot microservice 1030. This may comprise updatingthe current workflow stage of the transaction object to be a workflowstage associated with a workflow microservice 1020. At step 1035,snapshot microservice 1030 may put the transaction object back to theSDP with the updated current workflow stage.

At step 1021, workflow microservice 1020 may poll the SDP fortransactions having a current workflow stage assigned to themicroservice, and at step 1023 the workflow microservice may retrievethe matching transaction objects. At step 1025, workflow microservice1020 may process the transaction objects according to its respectiveprocessing logic, which may include updating, adding, removing, and/orotherwise changing values of the transaction details, addenda data,and/or transaction metadata associated with the transaction object. Atstep 1027, workflow microservice 1020 may update the transactionobject's current workflow stage to indicate completion of processing bymicroservice 1020 and, at step 1029, put the updated transaction objectback to the SDP.

At step 1037, snapshot microservice 1030 may poll the SDP fortransactions and, at step 1039, determine transaction having changeddata. Snapshot microservice 1030, at step 1041, may record snapshot datacorresponding to the changed data as a result of processing by workflowmicroservices 1020. The snapshot microservice 1030 may, at step 1043,put the transaction object back to the SDP for further processing byworkflow microservices 1020.

FIG. 11 depicts a flowchart illustrating an example method 1100 toreplay a transaction (e.g., subject it to reprocessing) using a snapshotmicroservice on a transaction exchange platform, such as transactionexchange platform 320. Method 1100 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1100.

At step 1105, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

The transaction object may be processed by microservice 1120 in steps1121, 1123, 1125, 1127, and 1129 as described herein, for example insimilar fashion to that described with respect to FIG. 10 in steps 1021,1023, 1025, 1027, and 1029.

Snapshot microservice 1130 may record initial and changed snapshotinformation in steps 1131 and 1131, as described in greater detail abovewith respect to FIG. 10 in steps 1031, 1033, 1035, 1037, 1039, 1041, and1043.

At step 1135, snapshot microservice 1130 may receive a command to replaya workflow step for a transaction object. For example, a watchdogmicroservice may send snapshot microservice 1130 a command to replay thetransaction object in a first workflow stage.

At step 1137, snapshot microservice 1130 may use the stored snapshotinformation to rollback the transaction object to its state prior to thepoint of replay. The transaction object may be made to repeat an earlierstep of the workflow and be subject to re-processing by a microserviceto the workflow step indicated to be replayed. The snapshot microservice1130 may regenerate a transaction object using the snapshot datacorresponding to the transaction object from an earlier time, prior to apoint in processing that is subject to the rewind.

At step 1139, snapshot microservice 1130 may put the regeneratedtransaction object back on the SDP. Because the regenerated transactionobject has the earlier workflow stage, it will be picked up forre-processing by the earlier microservice.

Thus, according to some aspects, a computer-implemented method maycomprise steps comprising receiving a transaction object comprisingtransaction details, addenda data, and transaction metadata. Thetransaction metadata may comprise an indication of a workflowcorresponding to a transaction type of the transaction object, and acurrent workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The steps may further comprise adding the transactionobject to a streaming data platform. Adding the transaction object tothe streaming data platform may comprise setting the current workflowstage of the transaction object to an initialization stage. The stepsmay further comprise polling, by a snapshot microservice, the streamingdata platform to retrieve transactions matching the initializationstage. The initialization stage may be associated with the snapshotmicroservice. The steps may further comprise retrieving, by the snapshotmicroservice and from the streaming data platform, the transactionobject based on the current workflow stage matching the initializationstage; storing, by the snapshot microservice, snapshot datacorresponding to the transaction object; and updating the currentworkflow stage of the transaction object to a next workflow stage basedon completing storing, by the snapshot microservice, the snapshot datacorresponding to the transaction object. The method may compriseretrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data. The method may comprise determining, by the snapshotmicroservice and via the streaming data platform, that at least onevalue associated with the addenda data of the transaction object haschanged after the transaction object has left the initialization stage,and storing, by the snapshot microservice, snapshot data correspondingto the changed at least one value associated with the addenda data.

Determining that the at least one value associated with the addenda dataof the transaction object has changed may comprise retrieving, by thesnapshot microservice and from the streaming data platform, thetransaction object. The steps may further comprise determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully, and causing the first microservice to repeatprocessing of the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice. Causing the first microservice torepeat processing of the transaction object may comprise regenerating,by the snapshot microservice, the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice, and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determininga number of times that the transaction object has undergone processingby the first microservice and, in response to determining that thenumber of times that the transaction object has undergone processing bythe first microservice exceeds a threshold value, rejecting thetransaction object as having failed processing associated with the firstmicroservice. The steps may further comprise flagging the transactionobject for further review based on rejecting the transaction and holdingthe transaction object in the first workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object toa second workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisecausing the transaction object to be processed by a third microservice.Updating the current workflow stage of the transaction object to thesecond workflow stage may be based on determining that processing by thethird microservice is completed. The snapshot microservice may recordsecond snapshot data corresponding to the transaction object from priorto causing the first microservice to repeat processing of thetransaction object. The second snapshot data may be maintained despitethe repeat processing of the transaction object.

The steps may further comprise determining, by the snapshot microserviceand via the streaming data platform, that at least one value associatedwith the transaction metadata has changed; retrieving, by the snapshotmicroservice and from the streaming data platform, the transactionobject based on determining that the at least one value has changed; andstoring, by the snapshot microservice, data corresponding to the changedat least one value associated with the transaction metadata. The nextworkflow stage may correspond to the first workflow stage associatedwith the first microservice. The initialization stage may correspond tothe first workflow stage. The snapshot microservice may generate atransaction history for the transaction object. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform. The snapshot microservicemay store snapshot data in an on-disk database.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform. Adding the transactionobject to the streaming data platform may comprise setting the currentworkflow stage of the transaction object to an initialization stage. Thesteps may further comprise polling, by a snapshot microservice, thestreaming data platform to retrieve transactions matching theinitialization stage. The initialization stage may be associated withthe snapshot microservice. The steps may further comprise retrieving, bythe snapshot microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the transaction object, updating thecurrent workflow stage of the transaction object to a next workflowstage based on completing storing, by the snapshot microservice, thesnapshot data corresponding to the transaction object; and retrieving,by a first microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching a firstworkflow stage. The first workflow stage may be associated with thefirst microservice based on the workflow corresponding to thetransaction type. The steps may further comprise processing, by thefirst microservice, the transaction object to modify the addenda data;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data.

The steps may further comprise determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise causing the transaction exchangeplatform to regenerate, by the snapshot microservice, the transactionobject based on the snapshot data corresponding to the transactionobject from prior to the start of the processing by the firstmicroservice; and return the regenerated transaction object to thestreaming data platform. A current workflow stage of the regeneratedtransaction object may be set to the first workflow stage. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform.Adding the transaction object to the streaming data platform maycomprise setting the current workflow stage of the transaction object toan initialization stage. The steps may further comprise polling, by asnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; and storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object,updating the current workflow stage of the transaction object to a nextworkflow stage based on completing storing, by the snapshotmicroservice, the snapshot data corresponding to the transaction object;and retrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data; determining, by the snapshot microservice and via thestreaming data platform, that at least one value associated with theaddenda data of the transaction object has changed after the transactionobject has left the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the changed at least onevalue associated with the addenda data; determining that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise regenerating, by the snapshotmicroservice, the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice; and returning the regeneratedtransaction object to the streaming data platform. A current workflowstage of the regenerated transaction object may be set to the firstworkflow stage.

Arbiter—Watchdog Microservice for Tracking, Monitoring, and Remediation

Some aspects described herein may provide a watchdog microservice on thetransaction exchange platform, configured to track the progress oftransaction objects through their respective workflows. “Watchdog,” whenreferring to the watchdog microservice, may refer to the functionalityof the watchdog microservice to observe and archive the progress oftransaction objects on the transaction exchange platform, and enforcethe associated workflows. Thus the watchdog microservice may also bereferred to as an observability and archive microservice, or Arbiter.The watchdog microservice may determine that a transaction object hascompleted the approval workflow based on the transaction objectcompleting each component step of the workflow, and may cause thecompleted transaction to be output from the transaction exchangeplatform. The watchdog microservice may also enforce the workflow,causing transactions to repeat and/or revisit problematic steps of theworkflow.

The watchdog microservice may track metrics and/or other statisticsassociated with the workflows, microservices, and/or transactions. Basedon the tracked workflow data, the watchdog microservice may be able toassess trends associated with a workflow, microservice, or transaction.The watchdog microservice may compare a metric and/or other statistic tothreshold performance values to determine when the workflow,microservice, or transaction is subject to abnormal or undesirableperformance complications. For example, the watchdog microservice coulddetermine that a particular microservice has a current averageprocessing time greater than a configured warning threshold, or outsidea typical range. Based on detecting abnormal or undesirable performanceof the workflow, microservice, or transaction, the watchdog microservicecan generate and/or implement a recommended corrective action. Examplecorrective actions may include causing a transaction to be replayed viaa snapshot microservice, and causing a workflow to be dynamicallyreconfigured using a configuration interface.

FIG. 9 , discussed above with respect to the snapshot microservice, alsodepicts watchdog microservice 980 and watchdog database 985. Watchdogmicroservice 980 may generate workflow tracking records for eachtransaction object on the transaction exchange platform 320, and maystore information indicating whether the transaction object completedeach step of the workflow along with timestamps and other suitablemetadata. The workflow tracking records may be stored in watchdogdatabase 985, which may comprise an in-memory database configured tosupport quick access and retrieval of records while on SDP 325.

The watchdog microservice 980 may serve as the judge (arbiter) indetermining when a transaction object has completed the workflowprocessing steps of its corresponding workflow. This is furtherdescribed with respect to FIG. 12 .

FIG. 12 depicts a flowchart illustrating an example method 1200 to trackworkflow progress and determine if a transaction has completed theworkflow on a transaction exchange platform, such as transactionexchange platform 320. Method 1200 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1200.

At step 1205, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1231, watchdog microservice 1230 may store an initial record fornew transaction objects on the SDP. Watchdog microservice 1230 mayidentify new transactions on the SDP, potentially as a result of theinitialization stage, and may generate new workflow tracking records forthe new transaction objects. Watchdog microservice 1230 may poll the SDPto retrieve new transactions as they are added. Additionally and/oralternatively, watchdog microservice 1230 may poll the SDP to retrieveall new transactions and determine which are new, as shown in step 1233.

Workflow microservices 1220 may process transaction objects on the SDPin the manners described above in detail. For example, illustrated steps1221, 1223, 1225, 1227, and 1229 may correspond to steps 1021, 1023,1025, 1027, and 1029 of FIG. 10 .

At step 1233, watchdog microservice 1230 may poll the SDP fortransactions and, at step 1235, determine transaction objects having achanged workflow stage. In some embodiments, watchdog microservice 1230may poll all transactions and determine which have changes. In otherembodiments, watchdog microservice 1230 may poll the SDP to requesttransaction that have changed.

At step 1237, watchdog microservice 1230 may record workflow trackingdata corresponding to the change in the workflow stage of thetransaction object. For example, watchdog microservice 1230 may update aworkflow tracking record associated with the transaction object toindicate it completed a workflow stage associated with a workflowmicroservice 1220. The watchdog microservice 1230 may further storeother metadata regarding the updated workflow stage, including atimestamp of the recorded change.

At step 1239, the watchdog microservice 1230 may determine whether thecurrent workflow stage of the transaction object (and/or the workflowtracking data) indicate that the transaction object has met therequisite steps of the workflow associated with the transaction type ofthe transaction objects. For example, the watchdog microservice 1230 mayassess whether the current workflow stage information of the transactionmetadata indicates completion of a series of steps that satisfy thecriteria of the workflow associated with a particular transaction typeof the transaction object.

At step 1241, the watchdog microservice 1230 may determine that theworkflow is not complete, and may proceed to step 1245 where thetransaction object is put back to the SDP after recording the workflowtracking information.

If, at step 1241, the watchdog microservice 1230 determines that theworkflow is complete, processing may proceed to step 1243 where thetransaction object is removed from the SDP of the transaction exchangeplatform and output as completed. For example, the transaction objectmay be updated with an indication that it completed the workflow and isapproved, and may be put to a public SDP 340 accessible to enterprisesystems and users 350.

Additionally and/or alternatively to the workflow completiondeterminations described above, the watchdog microservice 980/1230 mayenforce the individual steps of the workflow. The watchdog microservicemay assess whether a current workflow stage indicates a valid workflowstage under the restrictions of the workflow structure. If the currentworkflow stage of the transaction object is not valid, the watchdogmicroservice may cause the transaction object to be processed by one ormore appropriate microservices associated with the workflow, therebyenforcing the workflow. Working in conjunction with the snapshotmicroservice, the watchdog microservice may cause a transaction torepeat a step of the workflow by reverting the transaction object to anearlier state in response to detecting problems.

According to some aspects, the watchdog microservice may track metricsand/or other statistics associated with the workflows, microservices,and/or transactions. Based on the tracked workflow data, the watchdogmicroservice may be able to assess trends associated with a workflow,microservice, or transaction. The watchdog microservice may compare ametric and/or other statistic to threshold performance values todetermine when the workflow, microservice, or transaction is subject toabnormal or undesirable performance complications. This is describedfurther below with respect to FIG. 13 .

FIG. 13 depicts a flowchart illustrating an example method 1300 to trackworkflow progress and recommend corrective action based on performancemetrics on a transaction exchange platform, such as transaction exchangeplatform 320. Examples of performance metrics include, for example, howlong it takes a transaction to complete an associated workflow fromstart to finish. As will be discussed, performance metrics may bemeasured at any suitable level, for example per transaction, per groupof transaction, within a time frame, within a sample, and the like.Method 1300 may be performed by any suitable computing device and/orcombination of computing devices, referred to as the system implementingmethod 1300.

At step 1305, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1310, the watchdog microservice may track progress oftransaction objects on the SDP through the microservices and workflowsassociated with a transaction type of the transaction object, asdescribed above with respect to FIG. 12 .

At step 1315, the watchdog microservice may determine one or moreperformance metrics associated with the transaction exchange platform,one or more workflows, one or more microservices, types of transactions,groups of transactions, individual transactions, and/or any suitablegranularity. The watchdog microservice may record how long it takes atransaction to move through its corresponding workflow, frommicroservice to microservice. This time may be recorded against upperand/or lower control limits with a rolling time period. The time periodmay be taken into account and normalized against business cycles (forexample: weekends are different than work days and certain hours of thework day look very different). Other metrics may be considered besidesprocessing time, such as throughput (volume), error rates, approve/denyrates, paths taken in branching workflows, and/or any other suitablemetric.

Metrics may be tracked at any desired level of granularity. For example,the watchdog microservice may track how long transaction take toprogress through the ACH workflow, and may assess whether this is withinhistorical performance ranges. Similarly, the watchdog microservice maytrack how long a particular microservice takes to process transactionsover the last five minutes and determine when this rises above a warninglevel, which may indicate a problem with the microservice. The watchdogmicroservice may determine baseline performance metrics for thetransaction exchange platform, workflows, microservices, and the like.Current metrics may be compared to these baseline metrics to determineand address abnormal performance.

At step 1320, the watchdog microservice may determine at least onerecommended action based on the performance metrics. Many correctiveactions may be recommended by the watchdog microservice, which mayflexibly adapt and learn suitable processes for responding to abnormalsystem conditions. A common recommended corrective action may be tocommand replay of an earlier workflow stage for a transaction or groupof transactions. Working with the snapshot microservice, the watchdogmicroservice can cause a transaction object to revert to an earlierstate, where the reversion to the current workflow stage of thetransaction object would cause it to be processed again by anappropriate microservice. Where a particular microservice is showingperformance abnormalities across a range of transactions, the watchdogmicroservice may determine that the particular microservice is havingproblems and recommend a suitable corrective action. As an example, thewatchdog microservice may determine that a dynamic reconfiguration toimplement alternate processing workflows, addressing the issuespresented by the particular microservice, represents a suitablecorrective action. The watchdog microservice may coordinate with theconfiguration interface to effect a reconfiguration of the workflow andthe corresponding microservices, potentially temporarily. In someimplementations, dynamic reconfiguration of a workflow, microservice, ortransaction may be recommended and implemented once successive replaysthrough the snapshot microservice have failed. Such reconfiguration mayaddress patterns of failure that become apparent from repeat errors fromthe microservices/workflows.

The watchdog microservice may implement other corrective actions aswell. For example, the watchdog microservice may utilize machinelearning techniques to self-optimize the workflows based on any suitablefeature, such as enhancing actions (rather than corrective action),security lockdown against intrusions, speed throughput, prioritizedrouting, restart, and most any other incident, administrative, ormanagement handling. The watchdog microservice provides a usefulinterface and allows machine learning collector agents to be deployed onthe transaction exchange platform to gather system state information foruse in optimizing and managing the transaction exchange platform. Othermetrics in addition to performance, security, resiliency,responsiveness, robustness, visibility, etc. may be considered by thewatchdog microservice, and the flexibility and comprehensive scope ofthe watchdog microservices may enable powerful management of thetransaction exchange platform.

At step 1325, the watchdog microservice may cause the recommended actionto be implemented. For example, the watchdog microservice may commandthe snapshot microservice to replay a workflow stage for the transactionobject. As another example, the watchdog microservice may command theconfiguration interface to dynamically reconfigure one or more workflowsand/or microservices based on the performance metric.

Subsequent to implementing the corrective action, the watchdogmicroservice may determine that successful processing is completed instep 1330. Or the watchdog microservice may determine that processinghas failed in step 1340, and may output the transaction for furtherreview (manually and/or automatically), and may generate anotherrecommended action, at step 1345.

According to some aspects, and as discussed above, the watchdogmicroservice may recommend as a corrective action replay of an earlierworkflow stage for a transaction or group of transactions. Working withthe snapshot microservice, the watchdog microservice can cause atransaction object to revert to an earlier state, where the reversion tothe current workflow stage of the transaction object would cause it tobe processed again by an appropriate microservice. This is describedfurther below with respect to FIG. 14 .

FIG. 14 depicts a flowchart illustrating an example method 1400 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1400 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1400. FIG. 14 may combine aspects of FIGS. 11 and 13, as explained further below.

At step 1405, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1421, watchdogmicroservice 1420 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1423, watchdog microservice 1420 may determine that atransaction object should replay a workflow stage. For example, asdiscussed above with respect to FIG. 13 , the watchdog microservice maydetermine that a transaction object did not correctly complete theworkflow step and/or that the microservice associated with the step isexperiencing abnormal performance issues. At step 1425, the watchdogmicroservice 1420 may command snapshot microservice 1430 to replay thetransaction object at the earlier workflow stage.

Snapshot microservice 1430 may store snapshot data records fortransaction objects on the SDP in steps 1431 and 1433, as discussedabove in FIGS. 10 and 11 . At step 1435, snapshot microservice 1430 mayreceive the command to replay the workflow step for the transactionobject from the watchdog microservice 1420. Snapshot microservice mayrollback the transaction object and reinject it to the SDP at steps 1437and 1439, in the manner described above with respect to FIG. 11 .

At step 1441, watchdog microservice 1420 may determine if the replayedworkflow stage was processed successfully. If it processed successful,processing may proceed to step 1443 where the transaction workflowcontinues.

If, at step 1441, watchdog microservice 1420 determines that processingdid not complete successfully, watchdog microservice 1420 may determinewhether a maximum number of rollbacks have been attempted at step 1445.The snapshot microservice 1430 and/or watchdog microservice 1420 maymaintain a counter of the number of rollback/replay attempts. The numberof rollback/replay attempts is less than a configurable threshold, thenprocessing may return to step 1425 where watchdog microservice 1420again commands snapshot microservice 1430 to replay the transaction.

If, at step 1445, watchdog microservice 1420 determines that a maximumnumber of replay attempts have already occurred, then watchdogmicroservice may determine a failure of the transaction to progressthrough the workflow stage at step 1447. At step 1449 the watchdogmicroservice 1420 may determine a further recommended action, such astriggering a dynamic reconfiguration of the work follow. This is shownfurther in FIG. 15 .

FIG. 15 depicts a flowchart illustrating an example method 1500 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1500 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1500. FIG. 15 may combine aspects of FIGS. 11-14 ,as explained further below.

At step 1505, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1521, watchdogmicroservice 1520 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1522, the watchdog microservice may determine that a transactionobject should have a particular workflow stage replayed, and may orderthe snapshot microservice to replay the transaction as described in FIG.14 . Step 1522 may be optional, as watchdog microservice 1520 maydetermine to command dynamic reconfiguration even in the absence of areplayed transaction.

At step 1523, the watchdog microservice may determine that thetransaction exchange platform, one or more workflows, one or moremicroservices, or any other component should be modified. As discussedfurther above with respect to FIG. 13 , the watchdog microservice maymake this determination based on tracking one or more performancemetrics associated with the transaction exchange platform and/or any ofits components.

At step 1525, the watchdog microservice 1520 may command theconfiguration interface 1530 to reconfigure one or more microservices(and/or workflows, and/or any other component of the transactionexchange platform).

At step 1531, configuration interface 1530 may receive the command toreconfigure the microservices of the workflow, and may proceed throughsteps 1533 and 1535 to generate a configuration transaction object thatis pushed to the SDP to effect the desired reconfiguration, as describedabove with respect to FIG. 8 .

At step 1527, the watchdog microservice 1520 may command the snapshotmicroservice to replay the transaction object using the reconfiguredworkflow, if a particular transaction and/or group of transactions weresubject to erroneous and/or failed processing on the originalconfiguration.

At step 1529, the watchdog microservice 1520 may evaluate performance ofthe reconfigured workflow and continue to evaluate performance metricsassociated with aspects of the transaction exchange platform.

Thus, according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object and updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject. In response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed, the method may comprise: retrieving, bythe watchdog microservice and from the streaming data platform, thetransaction object based on determining that the current workflow stagehas changed and storing, by the watchdog microservice, workflow trackingdata corresponding to the transaction object and the changed currentworkflow stage.

The steps may further comprise determining, by the watchdogmicroservice, that the stored workflow tracking data corresponding tothe transaction object indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type and, inresponse to determining that the stored workflow tracking data indicatesthat the transaction object completed each stage of the workflowcorresponding to the transaction type, removing the transaction objectfrom the streaming data platform and outputting the transaction objectand an indication that the transaction object has completed theprocessing corresponding to the workflow. The current workflow stage ofthe transaction object may comprise a data structure indicatingcompletion status of each respective step of a plurality of processingsteps associated with the workflow. The steps may further comprise, inresponse to the determining that the current workflow stage of thetransaction object has changed, determining, by the watchdogmicroservice, whether the current workflow stage of the transactionobject is valid based on the workflow associated with the transactiontype and, in response to determining that the current workflow stage ofthe transaction object is not valid, causing, by the watchdogmicroservice, the transaction object to be processed by one or moremicroservices associated with the workflow. The watchdog microservicemay store workflow tracking data in an in-memory database. The workflowtracking data may comprise a timestamp and an indication of the changeto the current workflow stage of the transaction object. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one performance metric associatedwith the first microservice. The at least one performance metric maycorrespond to a single transaction object. The at least one performancemetric may correspond to a group of transaction objects over a period oftime. The steps may further comprise determining, by the watchdogmicroservice, that the at least one performance metric associated withthe first microservice fails to satisfy at least one thresholdperformance value; and performing at least one action based ondetermining that the at least one performance metric fails to satisfythe at least one threshold performance value. The steps may furthercomprise determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe workflow.

The steps may further comprise determining, by the watchdogmicroservice, that the at least one performance metric associated withthe workflow fails to satisfy at least one threshold performance value;and performing at least one action based on determining that the atleast one performance metric fails to satisfy the at least one thresholdperformance value. The steps may further comprise determining, by thewatchdog microservice and based on the workflow tracking data, at leastone baseline metric associated with the first microservice. The baselinemetric may correspond to processing performance by the firstmicroservice on a set of transaction objects over a period of time. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with a first transaction object processed by the firstmicroservice; determining that the at least one performance metricassociated with the first transaction object fails to satisfy athreshold relationship to the at least one baseline metric; andgenerating a recommended action to be taken on the first transactionobject. The recommended action may comprise causing the firsttransaction object to be re-processed by the first microservice. Therecommended action may comprise re-routing the first transaction objectto be processed by another microservice. The recommended action maycomprise changing the transaction type of the first transaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice, that the stored workflow tracking datacorresponding to the transaction object indicates that the transactionobject completed each stage of the workflow corresponding to thetransaction type; and in response to determining that the storedworkflow tracking data indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type,removing the transaction object from the streaming data platform andoutput the transaction object and an indication that the transactionobject has completed the processing corresponding to the workflow. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with the first microservice. The steps may further comprisedetermining, by the watchdog microservice, that the at least oneperformance metric associated with the first microservice fails tosatisfy at least one threshold performance value; and generating arecommended action based on determining that the at least oneperformance metric fails to satisfy the at least one thresholdperformance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice; andgenerating a graphic user interface display corresponding to the firstmicroservice and comprising the at least one performance metric.

And according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice.

The steps may further comprise polling, by the snapshot microservice,the streaming data platform to retrieve transactions matching aninitialization stage. Transactions may be added to the streaming dataplatform in the initialization stage. The initialization stage may beassociated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with addenda data of thetransaction object has changed after the transaction object has left theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data. The snapshot microservice may cause the firstmicroservice to repeat processing of the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice. Causing the firstmicroservice to repeat processing of the transaction object may compriseregenerating, by the snapshot microservice, the transaction object basedon snapshot data corresponding to the transaction object from prior tothe start of the processing by the first microservice; and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one performance thresholdvalue. The at least one performance metric may correspond to a singletransaction object. The at least one performance metric may correspondto a group of transaction objects over a period of time. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one baseline metric associated withthe first microservice. The baseline metric may correspond to processingperformance by the first microservice on a set of transaction objectsover a period of time. The steps may further comprise determining, bythe watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with a first transaction objectprocessed by the first microservice. Determining that the processing, bythe first microservice, of the transaction object did not completesuccessfully may be based on determining that the at least oneperformance metric associated with the first transaction object fails tosatisfy a threshold relationship to the at least one baseline metric.The steps may further comprise determining a number of times that thetransaction object has undergone processing by the first microservice;in response to determining that the number of times that the transactionobject has undergone processing by the first microservice exceeds athreshold value, rejecting the transaction object as having failedprocessing associated with the first microservice; and determining acorrective action for the transaction object based on rejecting thetransaction object. The corrective action may comprise re-routing thefirst transaction object to be processed by another microservice. Thecorrective action may comprise changing the transaction type of thetransaction object. The corrective action may comprise changing theindication of the workflow corresponding to the transaction type of thetransaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and polling, by asnapshot microservice, the streaming data platform to retrievetransactions matching an initialization stage. Transactions may be addedto the streaming data platform in the initialization stage. Theinitialization stage may be associated with the snapshot microservice.The steps may further comprise retrieving, by the snapshot microserviceand from the streaming data platform, the transaction object based onthe current workflow stage matching the initialization stage; storing,by the snapshot microservice, snapshot data corresponding to thetransaction object; and processing, by a first microservice, thetransaction object on the streaming data platform based on the currentworkflow stage matching a first workflow stage. The first workflow stagemay be associated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further comprisedetermining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data; updating the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object captured by a snapshot microservice.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform. Thetransaction object may be added to the streaming data platform in aninitialization stage. The steps may further comprise polling, by thesnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object; andprocessing, by the first microservice, the transaction object on thestreaming data platform based on the current workflow stage matching afirst workflow stage. The first workflow stage may be associated withthe first microservice based on the workflow corresponding to thetransaction type. The steps may further comprise determining, by thesnapshot microservice and via the streaming data platform, that at leastone value associated with addenda data of the transaction object haschanged after the transaction object has left the initialization stage;storing, by the snapshot microservice, snapshot data corresponding tothe changed at least one value associated with the addenda data;updating the current workflow stage of the transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the transaction object; and in response to determining,by a watchdog microservice and via the streaming data platform, that thecurrent workflow stage of the transaction object has changed, storingworkflow tracking data corresponding to the transaction object and thechanged current workflow stage; determining, by the watchdogmicroservice, that the processing, by the first microservice, of thetransaction object did not complete successfully; and causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice by: regenerating, by the snapshot microservice,the transaction object based on snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice; and returning the regenerated transaction object tothe streaming data platform. The current workflow stage of theregenerated transaction object may be set to the first workflow stage.The steps may further comprise determining, by the watchdog microserviceand based on the workflow tracking data, at least one baseline metricassociated with the first microservice. The baseline metric maycorrespond to processing performance by the first microservice on a setof transaction objects over a period of time. The steps may furthercomprise determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe first transaction object processed by the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thesingle transaction objects fails to satisfy a threshold relationship tothe at least one baseline metric.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfiguring the first microservice or a relatedsecond microservice based on determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully. The steps may further comprise causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice; and determining that the repeat processing of thetransaction object also did not complete successfully. Reconfiguring thefirst microservice or the related second microservice may be based ondetermining that the repeat processing of the transaction object failed.Reconfiguring the first microservice or a related second microservicemay comprise generating a configuration transaction object that may beconfigured to cause reconfiguration of the first workflow by causingreconfiguration of the first microservice. The configuration transactionobject may comprise transaction metadata that indicates a configurationworkflow and a current workflow stage of the configuration transactionobject. The steps may further comprise adding the configurationtransaction object to the streaming data platform; updating the currentworkflow stage of the configuration transaction object to the firstworkflow stage; retrieving, by the first microservice and from thestreaming data platform, the configuration transaction object based onthe current workflow stage matching the first workflow stage; andprocessing, by the first microservice, the configuration transactionobject to reconfigure the first microservice. Reconfiguring the firstmicroservice or the related second microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice or the related second microservicemay comprise reconfiguring the first microservice to modify at least oneoperation that the first microservice performs on transaction objectsassociated with the workflow. Reconfiguring the first microservice orthe related second microservice may comprise reconfiguring the relatedsecond microservice to cause removal of the first microservice from theworkflow. The second related microservice may be a predecessormicroservice that proceeds the first microservice in the workflow. Thesteps may further comprise determining, by the watchdog microservice, atleast one performance metric associated with the first micro service.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one threshold performancevalue. The steps may further comprise determining, by the watchdogmicroservice and based on the workflow tracking data, at least oneperformance metric associated with the workflow. Determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully may be based on determining that the at least oneperformance metric associated with the workflow fails to satisfy atleast one threshold performance value.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by thefirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfigure the first microservice based ondetermining that the processing, by the first microservice, of thetransaction object did not complete successfully by generating aconfiguration transaction object that may be configured to causereconfiguration of the first microservice and adding the configurationtransaction object to the streaming data platform. The steps may furthercomprise causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully. Reconfiguring the first microservice may be basedon determining that the repeat processing of the transaction objectfailed. Reconfiguring the first microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to modify at least one operation that the firstmicroservice performs on transaction objects associated with theworkflow. Reconfiguring the first microservice may comprisereconfiguring a related second microservice to cause the removal of thefirst microservice from the workflow. The second related microservicemay be a predecessor microservice that proceeds the first microservicein the workflow. The steps may further comprise determining, by thewatchdog microservice, at least one performance metric associated withthe first micro service. Determining that the processing, by the firstmicroservice, of the transaction object did not complete successfullymay be based on determining that the at least one performance metricassociated with the first microservice fails to satisfy at least onethreshold performance value. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the workflow. Determiningthat the processing, by the first microservice, of the transactionobject did not complete successfully may be based on determining thatthe at least one performance metric associated with the workflow failsto satisfy at least one threshold performance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully; and reconfiguring the first microservice or arelated second microservice, based on determining that the repeatprocessing of the transaction object also did not complete successfully.Reconfiguring the first microservice may comprise generating aconfiguration transaction object that may be configured to causereconfiguration of the first workflow by causing reconfiguration of thefirst microservice. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow, and acurrent workflow stage of the configuration transaction object.Reconfiguring the first microservice may further comprise adding theconfiguration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Reconfiguring the first microservice or the related second microservicemay cause transaction objects associated with the workflow to bedynamically re-routed.

Kharon & Mercury—Pause Microservice and Messaging Microservice

One or more aspects described herein may provide for the pausing of aworkflow and/or the processing of a transaction object. As describedabove, a transaction object may be processed by one or more workflowsand/or microservices. While the transaction object is being processed,the transaction exchange platform may determine that processing of thetransaction object needs to be paused. The determination that processingof the transaction object needs to be paused may be based on adetermination that processing of an entire workflow needed to be paused,for example, in response to a determination that the workflow needed tobe re-configured using the techniques described above. Additionally oralternatively, the determination that processing of the transactionneeds to be paused may be based on a request received from an externalthird-party. For example, a customer may request that the processing ofa transaction be paused or cancelled. The pause microservice describedherein provides techniques for pausing, or cancelling, the processing ofa transaction object. Additionally or alternatively, the determinationthat processing of the transaction object needs to be paused may bebased on a determination, by a microservice processing the transactionobject, that the transaction object may be missing information or haveincorrect information. In yet another example, the determination thatprocessing of the transaction object needs to be paused may be based ona determination, by a microservice processing the transaction object,that the transaction object may be fraudulent. In these cases, amessaging microservice may send one or more electronic communications toan external platform. An application programming interface (API) mayreceive responses, such as the missing information or an indication thatthe transaction object is not associated with a fraudulent transaction.Once the response is received, processing of the transaction object mayresume. By allowing the processing of transaction objects to be paused,the processing of the transaction objects may be handled more quicklyand efficiently, without having to resubmit transactions or withoutdisruptions for fraud investigations.

FIG. 16A and FIG. 16B illustrate a transaction processing system 1600that may be similar to transaction processing systems 300, 600, and/or900 of FIGS. 3A, 6, and 9 , respectively. Relative to systems 300, 600,and/or 900, transaction processing system 1600 may add pausemicroservice 1610, an API 1617, and/or messenger microservice 1620.

Pause microservice 1610 may operate on transaction exchange platform 320to pause transaction objects and maintain a record of paused transactionobjects. The status of paused transaction objects may be stored indatabase 1615, which may comprise on-disk storage capable of effectivelystoring large volumes of data. Pause microservice 1610 and database 1615may be configured to store state information for paused transactionobjects. Additionally or alternatively, pause microservice 1610 anddatabase 1615 may store the state of a transaction object, while detailsof the paused transaction object may be stored in a separate location,such as snapshot database 975. In yet another example, the state of apaused transaction object, as well as transaction metadata, may bestored in watchdog database 985, for example, in lieu of database 1615.

Pause microservice 1610 may be configured to identify and retrievetransaction objects added to SDP 325 with a pause request. Transactionobjects may be added to the SDP 325 with an indication that processingof the transaction object should be paused. That is, a microservice orAPI may indicate that processing of the transaction object should bepaused, for example, using a workflow stage included in the transactionmetadata. In some examples, the microservice or API may indicate theworkflow stage by appending a suffix (e.g., “.REQUESTPAUSE”) to thetransaction object. Pause microservice 1610 may monitor (e.g., listento) SDP 325 for transaction objects that include the suffix. Uponrecognizing the transaction objects with the suffix, pause microservice1610 may retrieve the transaction objects from SDP 325. In anacknowledgement of the pause, pause microservice 1610 may update thecurrent workflow stage of the transaction object. Continuing the exampleabove, the suffix may be changed from “.REQUESTPAUSE” to “.PAUSE” toindicate (e.g., acknowledge) that the transaction object has beenpaused. Pause microservice 1610 may wait for an API call to resumeprocessing of the transaction object or to terminate (e.g., stop)processing of the transaction object. When pause microservice 160receives an API call to resume processing of the transaction object,pause microservice 160 may update the current workflow stage of thetransaction object, for example, by removing the suffix. Pausemicroservice 160 may then return the transaction object to SDP 325without the suffix, and processing of the transaction object may resume.When pause microservice 1610 received an API call to cancel processingof the transaction object, pause microservice 1610 may update theworkflow stage of the transaction object to indicate that processing ofthe transaction object should be terminated (e.g., cancelled). In someexamples, pause microservice 1610 may update the workflow stage of atransaction object that has been cancelled by appending another suffix(e.g., “.SNAG”) to the transaction object. Transaction exchange platform320 may monitor for transaction objects with the cancelled workflowstatus and remove those transaction objects from the platform.

API 1617 may provide an interface for receiving external requests and/orresponses. For example, API 1617 may receive an external request from athird-party to pause or cancel the processing of a transaction object.Additionally or alternatively, API 1617 may receive responses, forexample, when missing information, misinformation, or fraud alerts aregenerated. As will be discussed in greater detail below, messengermicroservice 1620 may send electronic communications to externalthird-parties indicating that a transaction object is missinginformation, contains misinformation, and/or generated a fraud alert.Responses to those inquiries may be received by API 1617 and provided topause microservice 1610. Pause microservice 1610 may then update thetransaction object, for example, based on the information contained inthe response. Pause microservice 1610 may write the informationcontained in the response as addenda data to the transaction object.

While pause microservice 1610 has been described as pausing individualtransaction objects, it will be appreciated that pause microservice 1610may be used to pause transactions of a certain type. For example, if aplurality of transaction objects are paused, a flag may be triggered.One or more machine learning models may be used to identify thetransaction types and pause a workflow associated with the transactiontype, for example, using pause microservice 1610. That is, pausemicroservice 1610 may place all transaction objects associated with aworkflow in a paused state. The workflow may be updated using thetechniques described above. After the workflow has been updated, pausemicroservice 1610 may remove the paused state for all the transactionobjects, thereby allowing the transaction objects to resume processing.In another example, pause microservice 1610 may be used to posthumouslyidentify transaction objects that would have been of interest and usethose as input to the one or more machine learning models. In furtherexamples, pause microservice 1610 and API 1617 may be used to query thestatus of the processing of a transaction object. That is, API 1617 mayreceive a request for the status of a transaction object. Pausemicroservice 1610 may receive the request and provide a response to thequery via API 1617.

Messenger microservice 1620 may be configured to send requests foradditional processing of a transaction object to external third-parties.In this regard, messenger microservice 1620 may monitor (e.g., listento) SDP 325 to determine whether a paused transaction object requiresadditional information from a party external to the transaction exchangeplatform 320. In some instances, messenger microservice 1620 may monitorfor a flag. Additionally or alternatively, messenger microservice 1620may monitor the workflow status of transaction objects for pausedtransaction objects. Messenger microservice 1620 may then review thepaused transaction objects to determine why processing of thetransaction object was paused. For example, a paused transaction objectmay comprise an indication that the transaction object comprisesinsufficient information or improper information. Additionally oralternatively, a paused transaction object may comprise an indicationthat the transaction object generated a fraud alert.

Upon determining that the paused transaction object requires externalprocessing, messenger microservice 1620 may send (e.g. transmit) arequest for additional processing of the transaction object to theexternal party. The request for additional processing may comprisesending an electronic communication (e.g., email, API call, etc.) to athird-party. Additionally or alternatively, the request for additionalprocessing may comprise writing the transaction object to a publicstreaming data platform, such as Public SDP 340. In some instances,messenger microservice 1620 may transform the transaction object priorto the transmitting the request for additional processing. As notedabove, pause microservice 1610 may receive the response and write theadditional information to the transaction object as addenda data. Insome examples, messenger microservice 1620 may transform the responseprior to the pause microservice 1610 writing the information to thetransaction object.

While pause microservice 1610, API 1617, and messenger microservice 1620have been described as separate entities, it will be appreciated thatpause microservice 1610, API 1617, and/or messenger microservice 1620may be implemented as a single microservice as shown, for example inFIG. 16B. that is, pause microservice 1610 may comprise thefunctionality of both API 1617 and messenger microservice 1620. In thisregard, pause microservice 1617 may provide an interface between thetransaction exchange platform 320 and public SDP 340.

FIG. 17 depicts an illustrative method 1700 for pausing processing of atransaction object according to one or more aspects of the disclosure.Method 1700 may be performed by any suitable computing device and/orcombination of computing devices, referred to as the system implementingmethod 1700.

In step 1710, a system (e.g., a streaming data platform of a transactionexchange platform) may receive a transaction object. As noted above, thetransaction object may comprise transaction details and transactionmetadata. The transaction metadata may indicate a workflow correspondingto a transaction type of the transaction object. The workflowcorresponding to the transaction type comprises a plurality ofprocessing steps required to validate a given transaction of thetransaction type. Additionally or alternatively, the transactionmetadata may comprise a current workflow stage of the transactionobject. As will be discussed in greater detail below, the transactionmetadata may comprise one or more conditions that impact the processingof the transaction object.

In step 1731, microservice 1730, of a plurality of microservicesexecuting on the system, may retrieve a plurality of transactionobjects, including the transaction object received in step 1710. In step1732, microservice 1730 may determine whether the current workflow stageof the transaction object matches a workflow stage associated withmicroservice 1730. Based on a determination that the current workflowstage matches the workflow stage associated with first microservice1730, microservice 1730 may process the transaction object in step 1733.In step 1734, microservice 1730 may determine that processing of thetransaction object should be paused. The determination that processingshould be paused may be based on receiving a request to pause (orcancel) processing of the transaction object from an externalthird-party (e.g., a customer, a user, a party to the transaction, afraud alert department, a financial institution, etc.). Additionally oralternatively, the determination that processing of the transactionobject should be paused may be based on a determination that additionalprocessing external to the streaming data platform is required tocomplete the processing of the transaction object. The additionalprocessing may be based on an identification of missing information ormisinformation. Additionally or alternatively, the additional processingmay be based on a determination that processing of the transactionobject generated a fraud alert. Accordingly, the transaction object maybe reviewed to determine whether the transaction is fraudulent. In yetanother example, the determination that processing of the transactionobject should be paused may be based on a determination that processingof a workflow should be paused. In this regard, the workflow may beupdated using the techniques described above, and transactionsassociated with the workflow may be paused until the workflow update iscompleted.

When microservice 1730 determines that processing should not be paused,method 1700 proceeds to step 1735, with the microservice 1730 determinewhether processing is complete. If processing has not been completed,method 1700 returns to step 1733, with microservice 1730 continuing toprocess the transaction object. However, if processing has beencompleted, microservice 1730 may update the workflow stage of thetransaction object in step 1736 and return the transaction object, withthe updated workflow stage, to the SDP (e.g., SDP 325) in step 1740.

When microservice 1730 determines that processing should be paused, themethod 1700 proceeds to step 1737, where microservice 1730 may updatethe workflow stage of the transaction object to indicate a request topause processing of the transaction object. Microservice 1730, or anequivalent API, may update the workflow stage of the transaction objectto indicate a request to pause. Additionally or alternatively,microservice 1730 may generate the request to pause by appending asuffix (e.g., “.REQUESTPAUSE”) to the transaction object. After updatingthe workflow stage of the transaction object, microservice 1730 may addthe transaction object back to the SDP (e.g., SDP 325), in step 1740.

In step 1751, pause microservice 1750 may retrieve a plurality oftransaction objects from the SDP (e.g., SDP 325), similar to step 1731described above. In step 1752, pause microservice 1750 may determinewhether any of the plurality of transaction objects comprises a workflowstage indicating a request to pause. That is, pause microservice 1750may monitor (e.g., listen to) SDP (e.g., SDP 325) for transactionobjects that include a workflow stage indicating a request to pause, instep 1752. When none are found, pause microservice 1750 returns to step1751 to monitor for transaction objects with a request to pause.

When pause microservice 1750 recognizes transaction objects with aworkflow stage indicating a request to pause processing, pausemicroservice 1750 may update the current workflow stage of thetransaction object, in step 1753. As discussed above, updating theworkflow stage to a pause state may comprise updating the currentworkflow stage in the transaction metadata. Additionally oralternatively, updating the workflow stage to a pause state may comprisechanging a suffix of the transaction object from “.REQUESTPAUSE” to“.PAUSE.” These changes may indicate (e.g., acknowledge) that thetransaction object has been paused. After the workflow stage has beenupdated to indicate the pause state of the transaction object, pausemicroservice 1750 may add the transaction object to the streaming dataplatform, for example, in step 1740. The transaction object may comprisean acknowledgement indicating that processing of the transaction objecthas been paused. The acknowledgement may prevent other microservicesfrom processing the transaction object. Accordingly, the processing of aplurality of transaction objects, without a pause state, may continue bythe microservices in accordance with one or more workflows of thestreaming data platform, while the paused transaction object remainsunprocessed.

After a transaction object has been paused, pause microservice 1750 mayreceive an indication to resume processing of the transaction object, instep 1754. The indication to resume processing may be received from anexternal third-party, for example, via an API call. For example, theindication to resume processing may be from a party to the transactionwith missing, or corrected, information. Additionally or alternatively,the indication to resume processing may be from a device associated witha fraud investigation. In this example, the indication to resumeprocessing may be based on a determination that a transaction associatedwith the transaction object does not constitute fraud. In yet anotherexample, the indication to resume processing may be from anothermicroservice, such as the watchdog microservice described above. Thewatchdog microservice may generate an alert after a first predeterminedamount of time has elapsed since the transaction object was paused. Thealert may cause an indication that the transaction object is paused tobe displayed on a computing device. After a second predetermined amountof time has elapsed since the transaction object was paused, thewatchdog microservice may cause processing of the transaction object toresume, e.g., in step 1754. The indication to resume processing of thetransaction object may include an indication of whether to advanceprocessing to the next workflow stage. Alternatively, the indication toresume processing of the transaction object may include an indication tore-generate the transaction object and begin processing at a specificworkflow stage (e.g., the beginning, the last microservice to processthe transaction object, etc.).

In response to receiving an indication to resume processing, pausemicroservice 1750 may update the workflow stage of the transactionobject, in step 1755. The indication to resume processing may bereceived via an API call. Additionally, updating the workflow stage ofthe transaction object may cause pause microservice 1750 to remove asuffix from the transaction object. Additionally or alternatively, thepause microservice 1750 may update the workflow stage to indicate whichof the plurality of microservices should process the transaction object.For example, the workflow stage may be set to the “INIT” stage, whichindicates that the transaction object should be processed from thebeginning of the workflow. Alternatively, the workflow stage may be setto the microservice that last processed the transaction object. That is,the workflow stage may be set such that the microservice that lastprocessed the transaction object re-executes the transaction object.Re-execution may comprise regenerating, by the snapshot microservicedescribed above, the transaction object, for example, based on snapshotdata corresponding to the transaction object from prior to a start ofthe processing by the microservice and, as discussed in greater detailbelow with respect to FIG. 18 , any additional information that may havebeen received. In yet another alternative, the workflow stage may be setto the next microservice in a workflow. Once the workflow stage of thetransaction object has been updated to remove the paused state, pausemicroservice 1750 may return the transaction object to the SDP in step1740, where the transaction object may be processed by one or moreadditional microservices.

At step 1760, the system (e.g., a watchdog microservice) may determinethat the current workflow stage of the transaction object indicates thatall requisite processing steps of the workflow have been completed. If,at step 1760, the system determines that the workflow is complete,processing may proceed to step 1770 where the transaction object isremoved from the SDP of the transaction exchange platform and outputtedas complete. For example, the transaction object may be updated with anindication that it completed the workflow and is approved, and may beput to a public SDP 340 that is accessible to enterprise systems andusers 350. If, at step 1760, the system determines that the workflow isincomplete, processing may continue by the next microservice in theworkflow. The process may continue until each step of the workflow iscompleted. Once processing is complete, the transaction object may beremoved from the SDP of the transaction exchange platform and outputtedas complete, in step 1770. Removing the transaction object from the SDPmay comprise removing the transaction object from a schedulingsub-system, such as an external repository (e.g., Redis).

Although not shown in FIG. 17 , pause microservice 1750 may receive anindication to cancel processing of the transaction object, instead ofthe indication to resume processing in step 1754. When pausemicroservice 1750 receives an indication (e.g., API call) to cancelprocessing of the transaction object, pause microservice 1750 may updatethe workflow status of the transaction object, in step 1755, to indicatethat processing of the transaction object should be terminated (e.g.,cancelled). Pause microservice 1750 may update the workflow stage of atransaction object that has been cancelled. As noted above, updating theworkflow stage of a transaction object to indicate that the transactionobject has been cancelled may comprise appending a suffix (e.g.,“.SNAG”) to the transaction object. Transaction exchange platform maymonitor for transaction objects with the cancelled workflow stage andremove those transaction objects from the platform, e.g., in step 1770.

FIG. 18 depicts an illustrative method for pausing processing of atransaction object and requesting additional information for thetransaction object according to one or more aspects of the disclosure.Method 1800 may be performed by any suitable computing device and/orcombination of computing devices, referred to as the system implementingmethod 1800.

In step 1811, pause microservice 1810 may retrieve a plurality oftransaction objects from the SDP (e.g., SDP 325), similar to step 1751described above. In step 1812, pause microservice 1810 may determinewhich, if any, of the plurality of transaction objects comprise arequest to pause processing. If none of the plurality of transactionobjects comprise a request to pause processing, pause microservice 1810may return to step 1811 to monitor the SDP for transaction objects witha request to pause. However, when pause microservice 1810 identifiestransaction objects with a workflow stage indicating a request to pauseprocessing, pause microservice 1810 may update the current workflowstage of the transaction object in step 1813, using any of thetechniques described above. In some examples, the request to pause mayinclude an indication of why processing is being paused. For example,the indication may comprise an indication that the transaction objectcomprises insufficient information or improper (incorrect) information.Additionally or alternatively, the indication may be that thetransaction object generates a fraud alert and requires further reviewfrom a third-party (e.g., fraud department). In step 1814, pausemicroservice 1810 may add the transaction object to the streaming dataplatform with an acknowledgement indicating processing of thetransaction object has been paused. While the transaction object ispaused, the processing of the other transaction objects, by a pluralityof microservices, may continue in accordance with their associatedworkflows. Additionally or alternatively, pause microservice 1810 mayadd a flag, or another suitable indicator, to the paused transactionobject that indicates why processing of the transaction object has beenpaused.

In step 1821, messenger microservice 1820 may retrieve a plurality oftransaction objects from the SDP. The plurality of transaction objectsmay comprise the paused transaction object. In step 1822, messengermicroservice 1820 may determine whether the paused transaction objectrequires additional information from a party external to the streamingdata platform. If not, messenger microservice 1820 may continue tomonitor the SDP, e.g., in step 1821. However, when messengermicroservice 1820 determines that the paused transaction object requiresadditional information, messenger microservice 1820 may determine whatinformation is missing and/or who to direct an inquiry to regarding thebasis for pausing processing of the transaction object. As noted above,this additional information may be obtained via a flag, or some otherindicator, that provides a signal to messenger microservice 1820 aboutthe nature of the additional information that is required in order toallow processing of the paused transaction object to resume. In step1823, messenger microservice 1820 may transform the transaction object,for example, prior to transmitting the request for additional processingto a third-party. Transforming the transaction object may comprisechanging the format of the transaction object from a first format to asecond format that is suitable for an external platform. For example,the transaction object may be transformed (converted) into a JSON formatprior to being transmitted. In step 1824, messenger microservice 1820may send (e.g., transmit) a request for additional processing of thetransaction object to the external party. In some examples, transmittingthe request for additional processing may include sending an electroniccommunication to the external platform. Additionally or alternatively,transmitting the request for additional processing may comprise writingthe transaction object to a public streaming data platform. In someexamples, the system may receive an acknowledgement from the externalparty that additional processing has been received and is being handled.

In step 1815, pause microservice 1810 may receive a response to therequest for additional processing of the transaction object. Theresponse may be received via an API (e.g., API 1617). The response maycomprise the additional information or an indication that thetransaction object is not associated with a fraudulent transaction. Insome examples, the response may be transformed prior to updating thetransaction object with the additional information. The transformation(e.g., conversion) may be the inverse of the transformation performedabove by messenger microservice 1820. In step 1816, pause microservice1810 may update the paused transaction object based on the response. Forexample, pause microservice 1810 may write additional information to thetransaction object, for example, as addenda data. In step 1817, pausemicroservice may update the current workflow stage of the transactionobject to indicate that the transaction object may resume processing. Asdiscussed above, this indication may include restarting the workflow(e.g., setting the workflow stage to “INIT”), re-executing by the priormicroservice, and/or advancing the processing to the next microservicein the workflow. The process 1800 may conclude with pause microservice1810 returning the un-paused transaction object to SDP, e.g., SDP 325,in step 1830, so that processing according to the workflow may continue.

Occasionally, paused transaction objects may stall. FIG. 19 depicts anillustrative method for handling stalled transaction objects accordingto one or more aspects of the disclosure. Method 1900 may be performedby any suitable computing device and/or combination of computingdevices, referred to as the system implementing method 1900.

In step 1910, the system (e.g., a watchdog microservice) may monitor(e.g., listen to) the SDP. The system may retrieve a plurality oftransaction objects from the SDP. In particular, the system (e.g., thewatchdog microservice) may retrieve one or more transaction objects thatinclude an indication that processing of the transaction object has beenpaused. The system (e.g., the watchdog microservice) may storeinformation related to the transaction object, such as when thetransaction object was initially paused, the steps taken to remediatethe transaction object, etc. This information may be stored in adatabase, such as the watchdog database 985. In response to retrievingone or more paused transaction objects from the SDP, the system maydetermine whether a first predetermined amount of time has elapsed sincethe transaction object was initially paused, in step 1920. If the firstpredetermined amount of time has not elapsed, the system (e.g., thewatchdog microservice) may return to step 1910 to monitor the SDP.

However, when the first predetermined amount of time has elapsed, thesystem (e.g., the watchdog microservice) may generate an alertindicating that the transaction object remains paused. The alert may bedisplayed on one or more devices. Additionally or alternatively, thealert may provide one or more options for resuming processing of thepaused transaction object. The one or more options may comprise arequest for the missing or incorrect information, a confirmation thatthe transaction object is not associated with a fraudulent transaction,etc. Additionally or alternatively, the one or more options may comprisean option to re-submit the transaction object or resume processing ofthe transaction object.

In step 1940, the system (e.g., the watchdog microservice) may determinewhether a second predetermined amount of time has elapsed since thetransaction object was initially paused. If not, the system returns tostep 1910 to monitor the status of paused transaction objects. However,if a second predetermined amount of time has passed since thetransaction object was initially paused, method 1900 may proceed to step1950 where the system (e.g., the watchdog microservice) prompts actionfor the transaction object. These actions may include removing thepaused transaction object from the streaming data platform, updating theworkflow stage of the transaction object to begin processing of thetransaction object again, updating the workflow stage of the transactionobject to advance processing of the transaction object to the nextmicroservice in the workflow, updating the workflow stage of thetransaction object to re-execute the transaction object by themicroservice that last processed the transaction object, updating theworkflow of the transaction object to a different workflow, etc. Whenthe system prompts re-execution of the transaction object, the system(e.g., the snapshot microservice) may regenerate the transaction object,for example, based on snapshot data corresponding to the transactionobject from prior to a start of the processing by the microservice andreturn the re-generated transaction object to the SDP. In some examples,the watchdog microservice may cause processing of the transaction objectto change from a first workflow to a second workflow, different from thefirst workflow as described in U.S. application Ser. No. 17/859,081,entitled “Transaction Exchange Platform with Classification Microserviceto Generate Alternative Workflows,” the entirety of which isincorporated herein by reference. In this regard, the watchdogmicroservice, or another microservice of the transaction exchangeplatform, may review the transaction object to determine if thetransaction process could be processed by a different workflow. When thetransaction object can be processed by a different workflow, thetransaction exchange platform may change the workflow of the transactionobject. In some instances, the transaction exchange platform may receiveuser approval before changing the workflow of the transaction object.Changing the workflow of the transaction object may resolve the issuesthat caused the transaction to be paused, thereby improving theprocessing of transaction objects. Additionally or alternatively, thewatchdog microservice may cause the transaction object to be processedby a troubleshooter microservice. The troubleshooter microservice may beconfigured to fix (address) any problems and/or issues that arise withthe processing of the transaction object.

Instead of using the watchdog microservice to monitor for stalled ordelayed transaction objects, the pause microservice may stop theprocessing of transaction objects, for example, in response to apredetermined amount of time elapsing. In this regard, the addenda dataof a transaction object may include one or more parameters and/orconditions that indicate that a transaction object should be stopped.The one or more parameters may be timer conditions associated with thetransaction object. The timer conditions may be used in lieu of, or inconjunction with, the watchdog microservice. For example, the one ormore parameters may indicate that processing of a transaction objectshould be stopped if the transaction object has been paused for apredetermined amount of time. That is, if a timer associated with thetransaction object expires, processing of the transaction object may bestopped. In another example, the one or more parameters may indicatethat processing of a transaction object should be stopped if processingthe transaction object surpasses (e.g., exceeds) a predetermined dateand/or time. Based on the one or more parameters included in the addendadata, the pause microservice may stop processing of a transaction objectif the one or more parameters (e.g. conditions) are met (e.g.,satisfied). This may allow an administrator to verify some actionassociated with the transaction object, such as fraud. The pausemicroservice may automatically stop payment of the transaction object,for example, based on the fraud research taking too long or based on thetransaction object not having been processed by a certain date and/ortime.

In some instances, it may be desirable to schedule a payment orprocessing of a payment. In this regard, the pause microservicedescribed herein may implement a “pause and hold” functionality. Thepause microservice may be used to create a payment at some arbitrarytime and have it scheduled for processing via the associated theworkflow at a later date. This would allow a file of payments to beprocessed after banking hours and scheduled to run during banking hours,thereby allowing an administrator to verify one or more actionsassociated with the transactions, such as researching fraud andauto-stopping a payment. Additionally or alternatively, the pause andhold functionality may allow a user to set up recurring payments basedon the pause microservice's ability to create payments at arbitrarydates and/or times. Additionally, the pause microservice may be used,for example, if too much time elapses. That is, the pause microservicemay be used to remove, or otherwise restart, transactions that havestalled during processing. Additionally, an intentional delay may beintroduced for the processing of a transaction to allow time for slowerclearing systems to process before checking a status of the transaction.In this regard, a transaction object may include a scheduling timestampin the addenda. Upon realizing the transaction object included ascheduling timestamp, the system may initiate the transaction objectwith the current workflow stage set to pause. After the time associatedwith the scheduling timestamp passed, the pause microservice may set thecurrent workflow stage of the transaction object to the firstmicroservice in a workflow (e.g., INIT). The transaction object may thenbe processed in accordance with the workflow. Additionally, the addendadata may be used to override the transaction exchange platform's defaultbehavior to stop a payment, for example, if a timer expires. Finally,the transaction object may provide a release-at-timestamp and/orrelease-in-duration condition in the addenda data of a transactionobject to terminate transactions that are taking an inordinate amount oftime.

FIG. 20 depicts an illustrative method 2000 for delaying processing of atransaction object according to one or more aspects of the disclosure.Method 2000 may be performed by any suitable computing device and/orcombination of computing devices, referred to as the system implementingmethod 2000.

In step 2010, a system (e.g., a streaming data platform of a transactionexchange platform) may receive a transaction object in a paused state.In some examples, the transaction object may be placed on the SDP with apause request. Pause microservice 2020 may process the transactionobject with the pause request using any of the techniques describedabove. As noted above, the transaction object may include addenda data.The addenda data may indicate that processing of the transaction objectshould be paused until a predetermined condition occurs. For example,addenda data may indicate that processing of the transaction object isto occur at a predetermined time. That is, the addenda data may schedulethe processing of the transaction object. Additionally or alternatively,the addenda data may indicate that processing of the transaction objectmay not occur before a predetermined time. In these examples, theaddenda data may include a scheduling timestamp indicating whenprocessing of the transaction object may occur. In further examples, theaddenda data may indicate that the transaction object is associated witha recurring payment and that processing of the transaction object shouldoccur at predetermined intervals (e.g., weekly, monthly, yearly, etc.).

In step 2021, pause microservice 2020 may retrieve a plurality oftransaction objects from the SDP (e.g., SDP 325). In step 2022, pausemicroservice 2020 may determine whether a condition associated with thepaused transaction objects has occurred. As noted above, the conditionmay comprise whether the predetermined date and/or time has passed(elapsed) such that a scheduled transaction object may be processed. Ifthe condition has not occurred, pause microservice 2020 may continue tomonitor one or more paused transaction objections to determine whether acondition has occurred that would indicate that one or more pausedtransaction objects may be processed.

When the condition has occurred, pause microservice 2020 may update theworkflow stage of the transaction object to resume processing of thetransaction object. As noted above, this may be in response to apredetermined date and/or time elapsing or some other suitable conditionoccurring. The workflow stage may be set to “INIT” or any other suitableworkflow stage. The workflow stage may be updated using any of thetechniques described above. After the workflow stage has been updated toindicate an un-paused state, pause microservice 2020 may add thetransaction object to the SDP, for example, in step 2040. Thetransaction object may be then be processed by one or moremicroservices, in accordance with one or more workflows. For example,microservice 2030 may retrieve a plurality of transaction objects, instep 2031. In step 2032, microservice 2030 may determine whether thecurrent workflow stage of the transaction object matches a workflowstage associated with microservice 2030. Based on a determination thatthe current workflow stage matches the workflow stage associated withmicroservice 2030, microservice 2030 may process the transaction objectin step 2033. In step 2034, the microservice 2030 may determine whetherprocessing of the transaction object has been completed. If processinghas not been completed, method 2000 returns to step 2033, withmicroservice 2030 continuing to process the transaction object. However,if processing has been completed, microservice 2030 may update theworkflow stage of the transaction object in step 2035 and return thetransaction object, with the updated workflow stage, to the SDP (e.g.,SDP 325) in step 2040. At step 2050, the system (e.g., a watchdogmicroservice) may determine that the current workflow stage of thetransaction object indicates that all requisite processing steps of theworkflow have been completed. If, at step 2050, the system determinesthat the workflow is complete, processing may proceed to step 2060 wherethe transaction object is removed from the SDP of the transactionexchange platform and outputted as complete. Removing the transactionobject from the SDP may comprise removing the transaction object from ascheduling sub-system, such as an external repository (e.g., Redis). If,at step 2050, the system determines that the workflow is incomplete,processing may continue by the next microservice in the workflow. Theprocess may continue until each step of the workflow is completed. Onceprocessing is complete, the transaction object may be removed from theSDP of the transaction exchange platform and outputted as complete, instep 2060. As noted above, removing the transaction object from the SDPof the transaction exchange platform may comprise removing thetransaction object from a scheduling sub-system (e.g., Redis).

By including conditions on when transaction objects may be processed,the payment system allows for payments to be created at any time and bescheduled for processing at a later date. This may allow a file ofpayments to be processed after banking hours and scheduled to be run(e.g., processed) during normal banking hours. Furthermore, the pausingof transaction objects allows an intentional delay to be introduced toallow for slower clearing systems to clear transaction objects beforeprocessing additional transaction objects or checking the status of theslower workflows.

Additionally, conditions may be used to ensure that transaction objectsare processed in a timely manner. For example, the conditions mayinclude a timer. If the timer expires before a transaction object hasfinished processing, a microservice, such as the pause microservice, mayterminate processing of the transaction object. FIG. 21 shows an exampleof a method 2100 for managing transaction objects when one or moreconditions occur during processing of the transaction object inaccordance with one or more aspects of the disclosure. Method 2100 maybe performed by any suitable computing device and/or combination ofcomputing devices, referred to as the system implementing method 2100.

In step 2110, a system (e.g., a streaming data platform of a transactionexchange platform) may receive a transaction object. As noted above, thetransaction object may comprise transaction details and transactionmetadata. The transaction metadata may include one or more conditionsfor the transaction object. For example, the one or more conditions mayinclude at least one of a start time for the transaction object, an endtime for the transaction object, a timer, and the like. The start timefor the transaction object may indicate a time after which processing ofthe transaction object may begin. The end time may indicate a time bywhich processing of the transaction object must be completed. Ifprocessing of the transaction object does not complete by the end time,processing of the transaction object may be terminated, for example,using the pause microservice. The timer may indicate a length of timethat processing of the transaction object is allowed to occur. If thetimer expires, processing of the transaction object may be terminated,for example, using the pause microservice.

In step 2121, microservice 2120, of a plurality of microservicesexecuting on the system, may retrieve a plurality of transactionobjects, including the transaction object received in step 2110. In step2122, microservice 2120 may determine whether the current workflow stageof the transaction object matches a workflow stage associated withmicroservice 2120. Based on a determination that the current workflowstage matches the workflow stage associated with microservice 2120,microservice 2120 may process the transaction object in step 2123. Instep 2124, microservice 2120 may determine whether processing of thetransaction object should be paused (or cancelled). When microservice2120 determines that processing should be paused (or cancelled), themethod 2100 may proceed to step 2127, where microservice 2120 may updatethe workflow stage of the transaction object to indicate a request topause processing of the transaction object. Microservice 2120, or anequivalent API, may update the workflow stage of the transaction objectto indicate a request to pause. Additionally or alternatively,microservice 2120 may generate the request to pause using any of thetechniques described above. After updating the workflow stage of thetransaction object, microservice 2120 may add the transaction objectback to the SDP (e.g., SDP 325), where the transaction object will beplaced in a pause state using the techniques described above withrespect to FIG. 17 .

Alternatively, when microservice 2120 determines that processing shouldnot be paused, method 2100 may proceed to step 2125, with themicroservice 2120 determining whether processing is complete. Ifprocessing has not been completed, method 2100 returns to step 2123,with microservice 2120 continuing to process the transaction object.However, if processing has been completed, microservice 2120 may updatethe workflow stage of the transaction object in step 21266 and returnthe transaction object, with the updated workflow stage, to the SDP(e.g., SDP 325) in step 2130. At step 2150, the system (e.g., a watchdogmicroservice) may determine that the current workflow stage of thetransaction object indicates that all requisite processing steps of theworkflow have been completed. If, at step 2150, the system determinesthat the workflow is complete, processing may proceed to step 2160 wherethe transaction object is removed from the SDP of the transactionexchange platform and outputted as complete. Conversely, if, at step2150, the system determines that the workflow is incomplete, processingmay continue by the next microservice in the workflow. The process maycontinue until each step of the workflow is completed. Once processingis complete, the transaction object may be removed from the SDP of thetransaction exchange platform and outputted as complete, in step 2160.

In some instances, pause microservice 2140 may monitor a plurality oftransactions to determine if one or more conditions associated with atransaction object have occurred. In step 2141, pause microservice 2141may monitor a plurality of transaction objects on the SDP (e.g., SDP325) and, specifically, those transaction objects that include one ormore conditions. Pause microservice 2140 may store transaction objectsand their associated conditions, for example, in a table, database, or asimilar storage mechanism. In step 2142, pause microservice 2140 maydetermine whether one or more conditions have occurred. As noted above,the one or more conditions may comprise at least one of an end time or atimer. Accordingly, pause microservice 2140 may determine whetherprocessing of the transaction object has completed by the end time orwhether the timer has expired. If the one or more conditions have notyet been met, then the process may return to step 2141 with the pausemicroservice 2140 continuing to monitor transaction objects and,especially, those with one or more conditions associated therewith.

If pause microservice 2140 determines that one or more conditions havebeen met (e.g., satisfied), pause microservice 2143 may update theworkflow of the transaction object. In some instances, the workflow ofthe transaction object may be updated to indicate that processing of thetransaction object should be terminated (e.g., cancelled), for example,if the end time has passed (e.g., elapsed) or the timer has expired.Pause microservice 2140 may update the workflow stage of a transactionobject using any of the techniques described above. For example, theworkflow stage of the transaction object may be updated to indicate thatprocessing of the transaction object should be terminated. Thisindication may be performed by appending a suffix (e.g., “.SNAG”) to thetransaction object. Transaction exchange platform may monitor fortransaction objects with the cancelled workflow stage and remove thosetransaction objects from the platform, e.g., in step 2160.

Thus, according to some embodiments, a computer-implemented method mayreceive a transaction object comprising transaction details andtransaction metadata. In particular, a streaming data platform of atransaction exchange platform may receive the transaction object. Thetransaction metadata may comprise an indication of a workflowcorresponding to a transaction type of the transaction object and acurrent workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to validate a given transaction of thetransaction type. The computer-implemented method may further compriseretrieving, by a first microservice of a plurality of microservices, aplurality of transaction objects from the streaming data platform. Theplurality of transaction objects may comprise the transaction object.The computer-implemented method may further comprise determining, by thefirst microservice, whether the current workflow stage of thetransaction object matches a first workflow stage associated with thefirst microservice. Based on a determination that the current workflowstage matches the first workflow stage associated with the firstmicroservice, the computer-implemented method may comprise processing,by the first microservice, the transaction object. Thecomputer-implemented method may further comprise determining, by thefirst microservice and during the processing of the transaction object,that the processing of the transaction object should be paused.Determining that the processing of the transaction object should bepaused may be based on a determination that additional processingexternal to the streaming data platform is required to complete theprocessing of the transaction object. The computer-implemented methodmay comprise updating, by the first microservice, the current workflowstage of the transaction object to indicate a request to pause theprocessing of the transaction object. The computer-implemented methodmay further comprise adding, by the first microservice, the transactionobject to the streaming data platform with an indication of the requestto pause the processing of the transaction object. Thecomputer-implemented method may comprise retrieving, by a pausemicroservice, a second plurality of transaction objects from thestreaming data platform. The second plurality of transaction objects maycomprise the transaction object with the request to pause. Thecomputer-implemented method may comprise adding, by the pausemicroservice, the transaction object to the streaming data platform withan acknowledgement indicating that processing of the transaction objecthas been paused. The processing of the plurality of transaction objects,by the plurality of microservices, may continue in accordance with aworkflow of the streaming data platform while the transaction object ispaused. The computer-implemented method may further comprisetransmitting, to a party external to the streaming data platform, anindication that processing of the transaction object has been paused.The computer-implemented method may comprise receiving, from the partyexternal, a second acknowledgement that processing of the transactionobject has been paused. The computer-implemented method may furthercomprise generating, by a watchdog microservice and based on apredetermined amount of time after the transaction object was initiallypaused, an alert indicating that the transaction object remains paused.

In some instances, the computer-implemented method may comprise thepause microservice receiving an indication to resume processing of thetransaction object. The pause microservice may update a workflow stageof the transaction object that causes processing of the transactionobject to advance to a third microservice. Additionally oralternatively, the pause microservice may update a workflow stage of thetransaction object that causes the transaction object to be re-executedby the first microservice. In some examples, the computer-implementedmethod may comprise regenerating, by a snapshot microservice and basedon the indication to resume processing indicating re-execution, thetransaction object based on snapshot data corresponding to thetransaction object from prior to a start of the processing by the firstmicroservice. The computer-implemented method may further comprisereturning the regenerated transaction object to the streaming dataplatform. The current workflow stage of the regenerated transactionobject may be set to the first workflow stage. In some examples, theindication to resume processing of the transaction object may bereceived from a watchdog microservice after a predetermined amount oftime has elapsed.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice, a pause microservice, a watchdogmicroservice, and/or a snapshot microservices. The first microserviceand the pause microservice may be automatically configured to watch fortransactions on the streaming data platform with workflow stagescorresponding to the first microservice and/or the pause microservice.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to receive thetransaction object. The transaction metadata may comprise an indicationof a workflow corresponding to a transaction type of the transactionobject and a current workflow stage of the transaction object. Theworkflow corresponding to the transaction type may comprise a pluralityof processing steps required to validate a given transaction of thetransaction type. The instructions, when executed by the at least oneprocessor, may further cause the platform to retrieve, by a firstmicroservice of a plurality of microservices, a plurality of transactionobjects from the streaming data platform. The plurality of transactionobjects may comprise the transaction object. The instructions, whenexecuted by the at least one processor, may further cause the platformto determine, by the first microservice, whether the current workflowstage of the transaction object matches a first workflow stageassociated with the first microservice. The instructions, when executedby the at least one processor, may further cause the platform toprocess, by the first microservice, the transaction object, for example,based on a determination that the current workflow stage matches thefirst workflow stage associated with the first microservice. Theinstructions, when executed by the at least one processor, may furthercause the platform to determine, by the first microservice and duringthe processing of the transaction object, that the processing of thetransaction object should be paused. Determining that the processing ofthe transaction object should be paused may be based on a determinationthat additional processing external to the streaming data platform isrequired to complete the processing of the transaction object. Theinstructions, when executed by the at least one processor, may furthercause the platform to update, by the first microservice, the currentworkflow stage of the transaction object to indicate a request to pausethe processing of the transaction object. The instructions, whenexecuted by the at least one processor, may further cause the platformto add, by the first microservice, the transaction object to thestreaming data platform with an indication of the request to pause theprocessing of the transaction object. The instructions, when executed bythe at least one processor, may further cause the platform to retrieve,by a pause microservice, a second plurality of transaction objects fromthe streaming data platform. The second plurality of transaction objectsmay comprise the transaction object with the request to pause. Theinstructions, when executed by the at least one processor, may furthercause the platform to add, by the pause microservice, the transactionobject to the streaming data platform with an acknowledgement indicatingthat processing of the transaction object has been paused. Theprocessing of the plurality of transaction objects, by the plurality ofmicroservices, may continue in accordance with a workflow of thestreaming data platform while the transaction object is paused. Theinstructions, when executed by the at least one processor, may furthercause the platform to transmit, to a party external to the streamingdata platform, an indication that processing of the transaction objecthas been paused. The instructions, when executed by the at least oneprocessor, may further cause the platform to receive, from the partyexternal, a second acknowledgement that processing of the transactionobject has been paused. The instructions, when executed by the at leastone processor, may further cause the platform to generate, by a watchdogmicroservice and based on a predetermined amount of time after thetransaction object was initially paused, an alert indicating that thetransaction object remains paused.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving, by a streaming data platform, atransaction object comprising transaction details and transactionmetadata, wherein the transaction metadata comprises an indication of aworkflow corresponding to a transaction type of the transaction object,wherein the workflow corresponding to the transaction type comprises aplurality of processing steps required to validate a given transactionof the transaction type; and a current workflow stage of the transactionobject; retrieving, by a first microservice of a plurality ofmicroservices and from the streaming data platform, a plurality oftransaction objects, wherein the plurality of transaction objectscomprises the transaction object; determining, by the firstmicroservice, whether the current workflow stage of the transactionobject matches a first workflow stage associated with the firstmicroservice; processing, by the first microservice and based on adetermination that the current workflow stage matches the first workflowstage associated with the first microservice, the transaction object;determining, by the first microservice and during the processing of thetransaction object, that the processing of the transaction object shouldbe paused; updating, by the first microservice, the current workflowstage of the transaction object to indicate a request to pause theprocessing of the transaction object; adding, by the first microservice,the transaction object with an indication of the request to pause theprocessing of the transaction object to the streaming data platform;retrieving, by a pause microservice and from the streaming dataplatform, a second plurality of transaction objects, wherein the secondplurality of transaction objects comprises the transaction object withthe request to pause; and adding, by the pause microservice, thetransaction object to the streaming data platform with anacknowledgement indicating that processing of the transaction object hasbeen paused, wherein processing of the plurality of transaction objects,by the plurality of microservices, continues in accordance with aworkflow of the streaming data platform.

According to other embodiments, a computer-implemented method maycomprise receiving, by a streaming data platform, a transaction objectcomprising transaction details and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, wherein the workflowcorresponding to the transaction type comprises a plurality ofprocessing steps required to validate a given transaction of thetransaction type and a current workflow stage of the transaction object.The computer-implemented method may further comprise adding thetransaction object to the streaming data platform. Thecomputer-implemented method may comprise receiving, by a pausemicroservice and from a third party external to the streaming dataplatform, a request to pause processing of the transaction object. Thecomputer-implemented method may comprise retrieving, by the pausemicroservice and from the streaming data platform, a plurality oftransaction objects. The plurality of transaction objects may comprisethe transaction object. The computer-implemented method may comprisechanging, by the pause microservice, the current workflow stage of thetransaction object to indicate a pause in the processing of thetransaction object. The computer-implemented method may comprise adding,by the pause microservice, the transaction object to the streaming dataplatform with an indication that processing of the transaction objecthas been paused. The processing of the plurality of transaction objects,by a plurality of microservices, may continue in accordance with aworkflow of the streaming data platform while the processing of thetransaction object is paused. The computer-implemented method maycomprise generating, by a watchdog microservice and based on apredetermined amount of time after the transaction object was initiallypaused, an alert indicating that the transaction object remains paused.The computer-implemented method may comprise receiving, by the pausemicroservice, an indication to resume processing of the transactionobject. The pause microservice may update a workflow stage of thetransaction object that causes processing of the transaction object toadvance to a next microservice in the workflow. Additionally oralternatively, the pause microservice may update a workflow stage of thetransaction object that causes the transaction object to be re-executedby an earlier microservice. The computer-implemented method may compriseregenerating, by a snapshot microservice and based on the indication toresume processing indicating re-execution, the transaction object basedon snapshot data corresponding to the transaction object from prior to astart of the processing by the earlier microservice. Thecomputer-implemented method may comprise returning the regeneratedtransaction object to the streaming data platform. A current workflowstage of the regenerated transaction object may be set to an earlierworkflow stage. The indication to resume processing of the transactionobject may be received from a watchdog microservice after apredetermined amount of time has elapsed. The computer-implementedmethod may comprise determining, by a watchdog microservice, that apredetermined amount of time after the transaction object was initiallypaused has elapsed and removing the transaction object from thestreaming data platform. The computer-implemented method may comprisereceiving a request to terminate processing of the transaction objectand removing the transaction object from the streaming data platform.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice, a pause microservice, a watchdogmicroservice, and/or a snapshot microservices. The first microserviceand the pause microservice may be automatically configured to watch fortransactions on the streaming data platform with workflow stagescorresponding to the first microservice and/or the pause microservice.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to receive, bythe streaming data platform, a transaction object comprising transactiondetails and transaction metadata, wherein the transaction metadatacomprises an indication of a workflow corresponding to a transactiontype of the transaction object, wherein the workflow corresponding tothe transaction type comprises a plurality of processing steps requiredto validate a given transaction of the transaction type; and a currentworkflow stage of the transaction object. The instructions, whenexecuted by the at least one processor, may further cause the platformto add the transaction object to the streaming data platform. Theinstructions, when executed by the at least one processor, may furthercause the platform to receive, by a pause microservice and from a thirdparty external to the streaming data platform, a request to pauseprocessing of the transaction object. The instructions, when executed bythe at least one processor, may further cause the platform to retrieve,by the pause microservice and from the streaming data platform, aplurality of transaction objects, wherein the plurality of transactionobjects comprises the transaction object; changing, by the pausemicroservice, the current workflow stage of the transaction object toindicate a pause in the processing of the transaction object. Theinstructions, when executed by the at least one processor, may furthercause the platform to add, by the pause microservice, the transactionobject to the streaming data platform with an indication that processingof the transaction object has been paused, wherein processing of theplurality of transaction objects, by a plurality of microservices,continues in accordance with a workflow of the streaming data platform.The instructions, when executed by the at least one processor, mayfurther cause the platform to generate, by a watchdog microservice andbased on a predetermined amount of time after the transaction object wasinitially paused, an alert indicating that the transaction objectremains paused. The instructions, when executed by the at least oneprocessor, may further cause the platform to receive, by the pausemicroservice, an indication to resume processing of the transactionobject. The instructions, when executed by the at least one processor,may further cause the platform to regenerate, by a snapshot microserviceand based on the indication to resume processing indicatingre-execution, the transaction object based on snapshot datacorresponding to the transaction object from prior to a start of theprocessing by the earlier microservice, and return the regeneratedtransaction object to the streaming data platform, wherein a currentworkflow stage of the regenerated transaction object is set to theearlier workflow stage. The instructions, when executed by the at leastone processor, may further cause the platform to determine, by awatchdog microservice, that a predetermined amount of time after thetransaction object was initially paused has elapsed and remove thetransaction object from the streaming data platform. The instructions,when executed by the at least one processor, may further cause theplatform to receive a request to terminate processing of the transactionobject and remove the transaction object from the streaming dataplatform.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving, by a streaming data platform, atransaction object comprising transaction details and transactionmetadata, wherein the transaction metadata comprises an indication of aworkflow corresponding to a transaction type of the transaction object,wherein the workflow corresponding to the transaction type comprises aplurality of processing steps required to validate a given transactionof the transaction type; and a current workflow stage of the transactionobject; adding the transaction object to the streaming data platform;receiving, by a pause microservice and from a third party external tothe streaming data platform, a request to pause processing of thetransaction object; retrieving, by the pause microservice and from thestreaming data platform, a plurality of transaction objects, wherein theplurality of transaction objects comprises the transaction object;changing, by the pause microservice, the current workflow stage of thetransaction object to indicate a pause in the processing of thetransaction object; and adding, by the pause microservice, thetransaction object to the streaming data platform with an indicationthat processing of the transaction object has been paused, whereinprocessing of the plurality of transaction objects, by a plurality ofmicroservices, continues in accordance with a workflow of the streamingdata platform. The steps may also comprise generating, by a watchdogmicroservice and based on a predetermined amount of time after thetransaction object was initially paused, an alert indicating that thetransaction object remains paused. The steps may comprise receiving, bythe pause microservice, an indication to resume processing of thetransaction object. The steps may comprise regenerating, by a snapshotmicroservice and based on the indication to resume processing indicatingre-execution, the transaction object based on snapshot datacorresponding to the transaction object from prior to a start of theprocessing by the earlier microservice, and returning the regeneratedtransaction object to the streaming data platform, wherein a currentworkflow stage of the regenerated transaction object is set to theearlier workflow stage. The steps may comprise determining, by awatchdog microservice, that a predetermined amount of time after thetransaction object was initially paused has elapsed and removing thetransaction object from the streaming data platform. The steps maycomprise receiving a request to terminate processing of the transactionobject and removing the transaction object from the streaming dataplatform.

Thus, according to some embodiments, a computer-implemented method maycomprise receiving, by a streaming data platform of a transactionexchange platform, a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to validate a given transactionof the transaction type. The computer-implemented method may comprisedetermining, by the first microservice during processing of thetransaction object, that the processing of the transaction object shouldbe paused, for example, in response to retrieving a plurality oftransaction objects from the streaming data platform and based on adetermination that the current workflow stage of the transaction objectmatches a first workflow stage associated with a first microservice. Thecomputer-implemented method may comprise updating, by the firstmicroservice, the current workflow stage of the transaction object toindicate a request to pause the processing of the transaction object.The computer-implemented method may further comprise adding, by thefirst microservice, the transaction object with an indication of therequest to pause the processing of the transaction object to thestreaming data platform. The computer-implemented method may compriseretrieving, by a pause microservice and from the streaming dataplatform, a second plurality of transaction objects. The secondplurality of transaction objects may comprise the transaction objectwith the request to pause. The computer-implemented method may compriseadding, by the pause microservice, the transaction object to thestreaming data platform with an acknowledgement indicating thatprocessing of the transaction object has been paused. Processing of theplurality of transaction objects, by the plurality of microservices, maycontinue in accordance with a workflow of the streaming data platformwhile process of the transaction object is paused. Thecomputer-implemented method may comprise retrieving, by a messengermicroservice, a third plurality of transaction objects. The thirdplurality of transaction objects may comprise the paused transactionobject. The computer-implemented method may comprise determining, by themessenger microservice, that the paused transaction object requiresadditional information from a party external to the streaming dataplatform. The computer-implemented method may comprise transmitting, bythe messenger microservice and based on a determination that thetransaction object requires additional information, a request foradditional processing of the transaction object to the party external tothe streaming data platform. The computer-implemented method maycomprise receiving, by the pause microservice from the party external tothe streaming data platform via an application programming interface, aresponse to the request for additional processing of the transactionobject, wherein the response comprises the additional information. Thecomputer-implemented method may comprise updating, by the pausemicroservice, the paused transaction object based on the response. Thecomputer-implemented method may further comprise updating, by the pausemicroservice, the current workflow stage of the transaction object toindicate that the transaction object is to be processed by a secondmicroservice. The computer-implemented method may comprise processing,by the second microservice and based on a determination that the currentworkflow stage matches a second workflow stage associated with thesecond microservice, the transaction object, for example, in response toretrieving a plurality of transaction objects from the streaming dataplatform. The computer-implemented method may comprise updating, by thesecond microservice, the current workflow stage of the transactionobject to indicate that the second microservice has completed processingof the transaction object. The computer-implemented method may compriseadding, by the second microservice, the transaction object to thestreaming data platform. The computer-implemented method may comprisedetermining that the current workflow stage of the transaction objectindicates that the transaction object has completed processingcorresponding to the workflow. The computer-implemented method maycomprise removing the transaction object from the streaming dataplatform and outputting the transaction object and an indication thatthe transaction object has completed the processing corresponding to theworkflow to a downstream system.

In some instances, the request to pause the processing of thetransaction object comprises at least one of an indication that thetransaction object comprises insufficient information, an indicationthat the transaction object comprises improper information, or anindication that the transaction object generates a fraud alert. Further,the request for additional processing may comprise sending an electroniccommunication or writing the transaction object to a public streamingdata platform. The computer-implemented method may comprisetransforming, by the messenger microservice and prior to thetransmitting the request for additional processing, the transactionobject and transmitting, by the messenger microservice, the transformedtransaction object with the request for additional processing. Thecomputer-implemented method may comprise transforming the response priorto updating the transaction object. The computer-implemented method maycomprise writing additional information as addenda data to thetransaction object when updating the paused transaction object based onthe response. The computer-implemented method may comprise regenerating,by a snapshot microservice and based on the indication to resumeprocessing indicating re-execution, the transaction object based onsnapshot data corresponding to the transaction object from prior to astart of the processing by the first microservice and informationreceived in the response to the request for additional processing of thetransaction object, and returning the regenerated transaction object tothe streaming data platform. The current workflow stage of theregenerated transaction object may be set to the first workflow stage ora second workflow stage. In some examples, the pause microservice andthe messenger microservice are a single microservice.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice, a pause microservice, a watchdogmicroservice, and/or a snapshot microservices. The first microserviceand the pause microservice may be automatically configured to watch fortransactions on the streaming data platform with workflow stagescorresponding to the first microservice and/or the pause microservice.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to receive, bythe streaming data platform of a transaction exchange platform, atransaction object comprising transaction details and transactionmetadata. The transaction metadata may comprise an indication of aworkflow corresponding to a transaction type of the transaction objectand a current workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to validate a given transaction of thetransaction type. The memory may store instructions that, when executedby the at least one processor, cause the transaction exchange platformto determine, by the first microservice during processing of thetransaction object, that the processing of the transaction object shouldbe paused, for example, in response to retrieving a plurality oftransaction objects from the streaming data platform and based on adetermination that the current workflow stage of the transaction objectmatches a first workflow stage associated with a first microservice. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to update, by thefirst microservice, the current workflow stage of the transaction objectto indicate a request to pause the processing of the transaction object.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to add, by thefirst microservice, the transaction object with an indication of therequest to pause the processing of the transaction object to thestreaming data platform. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to retrieve, by a pause microservice and from the streamingdata platform, a second plurality of transaction objects. The secondplurality of transaction objects may comprise the transaction objectwith the request to pause. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to add, by the pause microservice, the transaction object tothe streaming data platform with an acknowledgement indicating thatprocessing of the transaction object has been paused. Processing of theplurality of transaction objects, by the plurality of microservices, maycontinue in accordance with a workflow of the streaming data platformwhile process of the transaction object is paused. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to retrieve, by a messengermicroservice, a third plurality of transaction objects. The thirdplurality of transaction objects may comprise the paused transactionobject. The memory may store instructions that, when executed by the atleast one processor, cause the transaction exchange platform todetermine, by the messenger microservice, that the paused transactionobject requires additional information from a party external to thestreaming data platform. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to transmit, by the messenger microservice and based on adetermination that the transaction object requires additionalinformation, a request for additional processing of the transactionobject to the party external to the streaming data platform. The memorymay store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to receive, by thepause microservice from the party external to the streaming dataplatform via an application programming interface, a response to therequest for additional processing of the transaction object, wherein theresponse comprises the additional information. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to update, by the pause microservice,the paused transaction object based on the response. The memory maystore instructions that, when executed by the at least one processor,cause the transaction exchange platform to update, by the pausemicroservice, the current workflow stage of the transaction object toindicate that the transaction object is to be processed by a secondmicroservice. T The memory may store instructions that, when executed bythe at least one processor, cause the transaction exchange platform toprocess, by the second microservice and based on a determination thatthe current workflow stage matches a second workflow stage associatedwith the second microservice, the transaction object, for example, inresponse to retrieving a plurality of transaction objects from thestreaming data platform. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to update, by the second microservice, the current workflowstage of the transaction object to indicate that the second microservicehas completed processing of the transaction object. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to add, by the second microservice,the transaction object to the streaming data platform. The memory maystore instructions that, when executed by the at least one processor,cause the transaction exchange platform to determine that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the workflow. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to remove thetransaction object from the streaming data platform and outputting thetransaction object and an indication that the transaction object hascompleted the processing corresponding to the workflow to a downstreamsystem.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving, by a streaming data platform, atransaction object comprising transaction details and transactionmetadata, wherein the transaction metadata comprises an indication of aworkflow corresponding to a transaction type of the transaction object,wherein the workflow corresponding to the transaction type comprises aplurality of processing steps required to validate a given transactionof the transaction type; and a current workflow stage of the transactionobject; in response to retrieving a plurality of transaction objectsfrom the streaming data platform and based on a determination that thecurrent workflow stage of the transaction object matches a firstworkflow stage associated with a first microservice, determining, by thefirst microservice during processing of the transaction object, that theprocessing of the transaction object should be paused; updating, by thefirst microservice, the current workflow stage of the transaction objectto indicate a request to pause the processing of the transaction object;adding, by the first microservice, the transaction object with anindication of the request to pause the processing of the transactionobject to the streaming data platform; retrieving, by a pausemicroservice and from the streaming data platform, a second plurality oftransaction objects, wherein the second plurality of transaction objectscomprises the transaction object with the request to pause; adding, bythe pause microservice, the transaction object to the streaming dataplatform with an acknowledgement indicating that processing of thetransaction object has been paused, wherein processing of the pluralityof transaction objects, by the plurality of microservices, continues inaccordance with a workflow of the streaming data platform; retrieving,by a messenger microservice, a third plurality of transaction objects,wherein the third plurality of transaction objects comprises the pausedtransaction object; determining, by the messenger microservice, that thepaused transaction object requires additional information from a partyexternal to the streaming data platform; transmitting, by the messengermicroservice and based on a determination that the transaction objectrequires additional information, a request for additional processing ofthe transaction object to the party external to the streaming dataplatform; receiving, by the pause microservice from the party externalto the streaming data platform via an application programming interface,a response to the request for additional processing of the transactionobject, wherein the response comprises the additional information;updating, by the pause microservice, the paused transaction object basedon the response; updating, by the pause microservice, the currentworkflow stage of the transaction object to indicate that thetransaction object is to be processed by a second microservice; inresponse to retrieving a plurality of transaction objects from thestreaming data platform, processing, by the second microservice andbased on a determination that the current workflow stage matches asecond workflow stage associated with the second microservice, thetransaction object; updating, by the second microservice, the currentworkflow stage of the transaction object to indicate that the secondmicroservice has completed processing of the transaction object; adding,by the second microservice, the transaction object to the streaming dataplatform; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow to a downstream system.

Thus, according to some embodiments, a computer-implemented method maycomprise receiving, by a streaming data platform of a transactionexchange platform, a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to validate a given transactionof the transaction type. The computer-implemented method may comprisedetermining, by a first microservice during processing of thetransaction object, that the processing of the transaction object shouldbe paused, for example, in response to retrieving a plurality oftransaction objects from the streaming data platform and based on adetermination that the current workflow stage of the transaction objectmatches a first workflow stage associated with the first microservice.The computer-implemented method may comprise updating, by the firstmicroservice, the current workflow stage of the transaction object toindicate a request to pause the processing of the transaction object.The computer-implemented method may comprise adding, by the firstmicroservice, the transaction object with an indication of the requestto pause the processing of the transaction object to the streaming dataplatform. The computer-implemented method may comprise retrieving, by apause microservice and from the streaming data platform, a secondplurality of transaction objects. The second plurality of transactionobjects may comprise the transaction object with the request to pause.The computer-implemented method may comprise adding, by the pausemicroservice, the transaction object to the streaming data platform withan acknowledgement indicating that processing of the transaction objecthas been paused, wherein processing of the plurality of transactionobjects, by the plurality of microservices, continues in accordance witha workflow of the streaming data platform. The computer-implementedmethod may comprise retrieving, by a watchdog microservice and from thestreaming data platform, a third plurality of transaction objects,wherein the third plurality of transaction objects comprises thetransaction object with an indication that processing of the transactionobject has been paused. The computer-implemented method may comprisegenerating, by the watchdog microservice and based on determining that apredetermined amount of time after the transaction object was initiallypaused, an alert indicating that the transaction object remains paused.The computer-implemented method may comprise removing, by the watchdogmicroservice and based on a second predetermined amount of time afterthe transaction object was initially paused, the transaction object fromthe streaming data platform. The computer-implemented method maycomprise updating, by the watchdog microservice and based on a secondpredetermined amount of time after the transaction object was initiallypaused, the current workflow stage of the transaction object. Thecurrent workflow stage of the transaction object may cause processing ofthe transaction object to advance to a second microservice orre-execution by the first microservice. The computer-implemented methodmay comprise regenerating, by a snapshot microservice and based on thecurrent workflow stage of the transaction object indicating re-executionby the first microservice, the transaction object based on snapshot datacorresponding to the transaction object from prior to a start of theprocessing by the first microservice, and returning the regeneratedtransaction object to the streaming data platform. Thecomputer-implemented method may comprise determining that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the workflow, andremoving the transaction object from the streaming data platform andoutputting the transaction object and an indication that the transactionobject has completed the processing corresponding to the workflow to adownstream system.

In some embodiments, the computer-implemented method may compriseretrieving, by a messenger microservice, a third plurality oftransaction objects. The third plurality of transaction objects maycomprise the paused transaction object. The computer-implemented methodmay comprise determining, by the messenger microservice, that the pausedtransaction object requires additional information from a party externalto the streaming data platform. The computer-implemented method maycomprise transmitting a request for additional processing of thetransaction object to the party external to the streaming data platform.The computer-implemented method may comprise receiving, by the secondmicroservice from the party external to the streaming data platform viaan application programming interface, a response to the request foradditional processing of the transaction object. Thecomputer-implemented method may comprise updating, by the secondmicroservice, the paused transaction object based on the response. Thecomputer-implemented method may comprise updating, by the secondmicroservice, the current workflow stage of the transaction object toindicate that processing of the transaction object is to resume. Thecomputer-implemented method may comprise resuming, based on theindication to resume processing, processing of the transaction object.The computer-implemented method may comprise writing additionalinformation as addenda data to the transaction object when updating thepaused transaction object based on the response. Thecomputer-implemented method may comprise transforming, by the messengermicroservice and prior to the transmitting the request for additionalprocessing, the transaction object and transmitting the transformedtransaction object with the request for additional processing.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice, a pause microservice, a watchdogmicroservice, and/or a snapshot microservices. The first microserviceand the pause microservice may be automatically configured to watch fortransactions on the streaming data platform with workflow stagescorresponding to the first microservice and/or the pause microservice.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to receive, by astreaming data platform of a transaction exchange platform, atransaction object comprising transaction details and transactionmetadata. The transaction metadata may comprise an indication of aworkflow corresponding to a transaction type of the transaction objectand a current workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to validate a given transaction of thetransaction type. The memory may store instructions that, when executedby the at least one processor, cause the transaction exchange platformto determine, by a first microservice during processing of thetransaction object, that the processing of the transaction object shouldbe paused, for example, in response to retrieving a plurality oftransaction objects from the streaming data platform and based on adetermination that the current workflow stage of the transaction objectmatches a first workflow stage associated with the first microservice.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to update, by thefirst microservice, the current workflow stage of the transaction objectto indicate a request to pause the processing of the transaction object.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to add, by thefirst microservice, the transaction object with an indication of therequest to pause the processing of the transaction object to thestreaming data platform. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to retrieve, by a pause microservice and from the streamingdata platform, a second plurality of transaction objects. The secondplurality of transaction objects may comprise the transaction objectwith the request to pause. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to add, by the pause microservice, the transaction object tothe streaming data platform with an acknowledgement indicating thatprocessing of the transaction object has been paused, wherein processingof the plurality of transaction objects, by the plurality ofmicroservices, continues in accordance with a workflow of the streamingdata platform. The memory may store instructions that, when executed bythe at least one processor, cause the transaction exchange platform toretrieve, by a watchdog microservice and from the streaming dataplatform, a third plurality of transaction objects, wherein the thirdplurality of transaction objects comprises the transaction object withan indication that processing of the transaction object has been paused.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to generate, bythe watchdog microservice and based on determining that a predeterminedamount of time after the transaction object was initially paused, analert indicating that the transaction object remains paused. The memorymay store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to remove, by thewatchdog microservice and based on a second predetermined amount of timeafter the transaction object was initially paused, the transactionobject from the streaming data platform. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to update, by the watchdogmicroservice and based on a second predetermined amount of time afterthe transaction object was initially paused, the current workflow stageof the transaction object. The current workflow stage of the transactionobject may cause processing of the transaction object to advance to asecond microservice or re-execution by the first microservice. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to regenerate, by asnapshot microservice and based on the current workflow stage of thetransaction object indicating re-execution by the first microservice,the transaction object based on snapshot data corresponding to thetransaction object from prior to a start of the processing by the firstmicroservice, and returning the regenerated transaction object to thestreaming data platform. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to determine that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow, and remove the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow to a downstream system.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving, by a streaming data platform, atransaction object comprising transaction details and transactionmetadata, wherein the transaction metadata comprises an indication of aworkflow corresponding to a transaction type of the transaction object,wherein the workflow corresponding to the transaction type comprises aplurality of processing steps required to validate a given transactionof the transaction type; and a current workflow stage of the transactionobject; in response to retrieving a plurality of transaction objectsfrom the streaming data platform and based on a determination that thecurrent workflow stage of the transaction object matches a firstworkflow stage associated with a first microservice, determining, by thefirst microservice during processing of the transaction object, that theprocessing of the transaction object should be paused; updating, by thefirst microservice, the current workflow stage of the transaction objectto indicate a request to pause the processing of the transaction object;adding, by the first microservice, the transaction object with anindication of the request to pause the processing of the transactionobject to the streaming data platform; retrieving, by a pausemicroservice and from the streaming data platform, a second plurality oftransaction objects, wherein the second plurality of transaction objectscomprises the transaction object with the request to pause; adding, bythe pause microservice, the transaction object to the streaming dataplatform with an acknowledgement indicating that processing of thetransaction object has been paused, wherein processing of the pluralityof transaction objects, by the plurality of microservices, continues inaccordance with a workflow of the streaming data platform; retrieving,by a watchdog microservice and from the streaming data platform, a thirdplurality of transaction objects, wherein the third plurality oftransaction objects comprises the transaction object with an indicationthat processing of the transaction object has been paused; andgenerating, by the watchdog microservice and based on determining that apredetermined amount of time after the transaction object was initiallypaused, an alert indicating that the transaction object remains paused.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A computer-implemented method comprising:receiving, by a streaming data platform, a transaction object comprisingtransaction details and transaction metadata, wherein the transactionmetadata comprises: an indication of a workflow corresponding to atransaction type of the transaction object, wherein the workflowcorresponding to the transaction type comprises a plurality ofprocessing steps required to validate a given transaction of thetransaction type; and a current workflow stage of the transactionobject; retrieving, by a first microservice of a plurality ofmicroservices and from the streaming data platform, a plurality oftransaction objects, wherein the plurality of transaction objectscomprises the transaction object; determining, by the firstmicroservice, whether the current workflow stage of the transactionobject matches a first workflow stage associated with the firstmicroservice; processing, by the first microservice and based on adetermination that the current workflow stage matches the first workflowstage associated with the first microservice, the transaction object;determining, by the first microservice and during the processing of thetransaction object, that the processing of the transaction object shouldbe paused; adding, by the first microservice, the transaction objectwith an indication of a request to pause the processing of thetransaction object to the streaming data platform; retrieving, by apause microservice and from the streaming data platform, a secondplurality of transaction objects, wherein the second plurality oftransaction objects comprises the transaction object with the request topause; adding, by the pause microservice, the transaction object to thestreaming data platform with an indication that processing of thetransaction object has been paused, wherein the transaction object isnot processed in accordance with a workflow based on the indication thatprocessing of the transaction object has been paused while processing ofthe plurality of transaction objects, by the plurality of microservices,continues in accordance with one or more workflows of the streaming dataplatform; updating, by the pause microservice, the current workflowstage of the transaction object to indicate that processing of thetransaction object is to resume; and resuming, based on the updatedcurrent workflow stage, processing of the transaction object accordingto the workflow.
 2. The computer-implemented method of claim 1, whereinthe determining that the processing of the transaction object should bepaused is based on a determination that additional processing externalto the streaming data platform is required to complete the processing ofthe transaction object.
 3. The computer-implemented method of claim 1,further comprising: transmitting, to a party external to the streamingdata platform, an indication that processing of the transaction objecthas been paused; and receiving, from the party external to the streamdata platform, a second acknowledgement that processing of thetransaction object has been paused.
 4. The computer-implemented methodof claim 3, further comprising: determining, by a watchdog microservice,that a predetermined amount of time has elapsed since the transactionobject was initially paused; and generating, by the watchdogmicroservice and based on a determination that the transaction objectremains paused, an alert.
 5. The computer-implemented method of claim 3,further comprising: receiving, from the party external to the streamingdata platform, additional information associated with the transactionobject; and updating, by the pause microservice, the transaction objectwith the additional information, wherein updating the current workflowstage of the transaction object to indicate that processing of thetransaction object is to resume is in response to updating thetransaction object with the additional information.
 6. Thecomputer-implemented method of claim 1, wherein resuming processing ofthe transaction object according to the workflow is based on the pausemicroservice receiving an indication to resume processing of thetransaction object.
 7. The computer-implemented method of claim 6,further comprising: updating, by the pause microservice and based on theindication to resume processing of the transaction object, the currentworkflow stage of the transaction object to indicate that processing ofthe transaction object is to advance to a third microservice.
 8. Thecomputer-implemented method of claim 6, further comprising: updating, bythe pause microservice and based on the indication to resume processingof the transaction object, the current workflow stage of the transactionobject to indicate that processing of the transaction object is toreturn to the first microservice.
 9. The computer-implemented method ofclaim 8, further comprising: re-generating, by a snapshot microserviceand based on an indication that the transaction object is to bere-executed by the first microservice, the transaction object based onsnapshot data corresponding to the transaction object from prior to astart of the processing by the first microservice; and returning there-generated transaction object to the streaming data platform, whereina current workflow stage of the re-generated transaction object is setto the first workflow stage.
 10. The computer-implemented method ofclaim 1, wherein resuming processing of the transaction object accordingto the workflow is based on receiving an indication to resume processingof the transaction object from a watchdog microservice after apredetermined amount of time has elapsed.
 11. A transaction exchangeplatform comprising: at least one processor; and memory storinginstructions that, when executed by the at least one processor, causethe transaction exchange platform to: receive, by a streaming dataplatform, a transaction object comprising transaction details andtransaction metadata, wherein the transaction metadata comprises: anindication of a workflow corresponding to a transaction type of thetransaction object, wherein the workflow corresponding to thetransaction type comprises a plurality of processing steps required tovalidate a given transaction of the transaction type; and a currentworkflow stage of the transaction object; retrieve, by a firstmicroservice of a plurality of microservices and from the streaming dataplatform, a plurality of transaction objects, wherein the plurality oftransaction objects comprises the transaction object; determine, by thefirst microservice, whether the current workflow stage of thetransaction object matches a first workflow stage associated with thefirst microservice; process, by the first microservice and based on adetermination that the current workflow stage matches the first workflowstage associated with the first microservice, the transaction object;determine, by the first microservice and during the processing of thetransaction object, that the processing of the transaction object shouldbe paused; add, by the first microservice, the transaction object withan indication of a request to pause the processing of the transactionobject to the streaming data platform; retrieve, by a pause microserviceand from the streaming data platform, a second plurality of transactionobjects, wherein the second plurality of transaction objects comprisesthe transaction object with the request to pause; add, by the pausemicroservice, the transaction object to the streaming data platform withan indication that processing of the transaction object has been paused,wherein the transaction object is not processed in accordance with aworkflow based on the indication that processing of the transactionobject has been paused while processing of the plurality of transactionobjects, by the plurality of microservices, continues in accordance withone or more workflows of the streaming data platform; update, by thepause microservice, the current workflow stage of the transaction objectto indicate that processing of the transaction object is to resume; andresume, based on the updated current workflow stage, processing of thetransaction object according to the workflow.
 12. The transactionexchange platform of claim 11, wherein the instructions, when executedby the at least one processor, cause the transaction exchange platformto determine that the processing of the transaction object should bepaused by determining that additional processing external to thestreaming data platform is required to complete the processing of thetransaction object.
 13. The transaction exchange platform of claim 11,wherein the instructions, when executed by the at least one processor,cause the transaction exchange platform to: transmit, to a partyexternal to the streaming data platform, an indication that processingof the transaction object has been paused; and receive, from the partyexternal to the stream data platform, a second acknowledgement thatprocessing of the transaction object has been paused.
 14. Thetransaction exchange platform of claim 13, wherein the instructions,when executed by the at least one processor, cause the transactionexchange platform to: determine, by a watchdog microservice, that apredetermined amount of time has elapsed since the transaction objectwas initially paused; and generate, by the watchdog microservice andbased on a determination that the transaction object remains paused, analert.
 15. The transaction exchange platform of claim 13, wherein theinstructions, when executed by the at least one processor, cause thetransaction exchange platform to: receive, from the party external tothe streaming data platform, additional information associated with thetransaction object; and update, by the pause microservice, thetransaction object with the additional information, wherein updating thecurrent workflow stage of the transaction object to indicate thatprocessing of the transaction object is to resume is in response toupdating the transaction object with the additional information.
 16. Thetransaction exchange platform of claim 11, wherein the instructions,when executed by the at least one processor, cause the transactionexchange platform to resume processing of the transaction objectaccording to the workflow is based on the pause microservice receivingan indication to resume processing of the transaction object.
 17. Thetransaction exchange platform of claim 16, wherein the instructions,when executed by the at least one processor, cause the transactionexchange platform to update a workflow stage of the transaction objectto indicate that processing of the transaction object is to advance to athird microservice.
 18. The transaction exchange platform of claim 16,wherein the instructions, when executed by the at least one processor,cause the transaction exchange platform to update a workflow stage ofthe transaction object to indicate that processing of the transactionobject is to return to the first microservice.
 19. The transactionexchange platform of claim 18, wherein the instructions, when executedby the at least one processor, cause the transaction exchange platformto: re-generate, by a snapshot microservice and based on an indicationthat the transaction object is to be re-executed by the firstmicroservice, the transaction object based on snapshot datacorresponding to the transaction object from prior to a start of theprocessing by the first microservice; and return the re-generatedtransaction object to the streaming data platform, wherein a currentworkflow stage of the re-generated transaction object is set to thefirst workflow stage.
 20. The transaction exchange platform of claim 14,wherein the instructions, when executed by the at least one processor,cause the transaction exchange platform to resume processing of thetransaction object according to the workflow based on receiving theindication to resume processing of the transaction object from awatchdog microservice after a predetermined amount of time has elapsed.21. One or more non-transitory computer readable media comprisinginstructions that, when executed, cause a transaction exchange platformto: receive, by a streaming data platform, a transaction objectcomprising transaction details and transaction metadata, wherein thetransaction metadata comprises: an indication of a workflowcorresponding to a transaction type of the transaction object, whereinthe workflow corresponding to the transaction type comprises a pluralityof processing steps required to validate a given transaction of thetransaction type; and a current workflow stage of the transactionobject; retrieve, by a first microservice of a plurality ofmicroservices and from the streaming data platform, a plurality oftransaction objects, wherein the plurality of transaction objectscomprises the transaction object; determine, by the first microservice,whether the current workflow stage of the transaction object matches afirst workflow stage associated with the first microservice; process, bythe first microservice and based on a determination that the currentworkflow stage matches the first workflow stage associated with thefirst microservice, the trans action object; determine, by the firstmicroservice and during the processing of the transaction object, thatthe processing of the transaction object should be paused; add, by thefirst microservice, the transaction object with an indication of arequest to pause the processing of the transaction object to thestreaming data platform; retrieve, by a pause microservice and from thestreaming data platform, a second plurality of transaction objects,wherein the second plurality of transaction objects comprises thetransaction object with the request to pause; and add, by the pausemicroservice, the transaction object to the streaming data platform withan indication that processing of the transaction object has been paused,wherein the transaction object is not processed in accordance with aworkflow based on the indication that processing of the transactionobject has been paused while processing of the plurality of transactionobjects, by the plurality of microservices, continues in accordance withone or more workflows of the streaming data platform; update, by thepause microservice, the current workflow stage of the transaction objectto indicate that processing of the transaction object is to resume; andresume, based on the updated current workflow stage, processing of thetransaction object according to the workflow.
 22. The one or morenon-transitory computer readable media of claim 21, wherein theinstructions, when executed, cause the transaction exchange platform todetermine that the processing of the transaction object should be pausedby determining that additional processing external to the streaming dataplatform is required to complete the processing of the transactionobject.
 23. The one or more non-transitory computer readable media ofclaim 21, wherein the instructions, when executed, cause the transactionexchange platform to: transmit, to a party external to the streamingdata platform, an indication that processing of the transaction objecthas been paused; and receive, from the party external to the stream dataplatform, a second acknowledgement that processing of the transactionobject has been paused.
 24. The one or more non-transitory computerreadable media of claim 23, wherein the instructions, when executed,cause the transaction exchange platform to: determine, by a watchdogmicroservice, that a predetermined amount of time has elapsed since thetransaction object was initially paused; and generate, by the watchdogmicroservice and based on a determination that the transaction objectremains paused, an alert.
 25. The one or more non-transitory computerreadable media of claim 23, wherein the instructions, when executed,cause the transaction exchange platform to: receive, from the partyexternal to the streaming data platform, additional informationassociated with the transaction object; and update, by the pausemicroservice, the transaction object with the additional information,wherein updating the current workflow stage of the transaction object toindicate that processing of the transaction object is to resume is inresponse to updating the transaction object with the additionalinformation.
 26. The one or more non-transitory computer readable mediaof claim 21, wherein the instructions, when executed, cause thetransaction exchange platform to resume processing of the transactionobject according to the workflow is based on the pause microservicereceiving an indication to resume processing of the transaction object.27. The one or more non-transitory computer readable media of claim 26,wherein the instructions, when executed, cause the transaction exchangeplatform to update a workflow stage of the transaction object toindicate that processing of the transaction object is to advance to athird microservice.
 28. The one or more non-transitory computer readablemedia of claim 26, wherein the instructions, when executed, cause thetransaction exchange platform to update a workflow stage of thetransaction object to indicate that processing of the transaction objectis to return to the first microservice.
 29. The one or morenon-transitory computer readable media of claim 28, wherein theinstructions, when executed, cause the transaction exchange platform to:re-generate, by a snapshot microservice and based on an indication thatthe transaction object is to be re-executed by the first microservice,the transaction object based on snapshot data corresponding to thetransaction object from prior to a start of the processing by the firstmicroservice; and return the re-generated transaction object to thestreaming data platform, wherein a current workflow stage of there-generated transaction object is set to the first workflow stage. 30.The one or more non-transitory computer readable media of claim 26,wherein the instructions, when executed, cause the transaction exchangeplatform to resume processing of the transaction object according to theworkflow based on receiving the indication to resume processing of thetransaction object from a watchdog microservice after a predeterminedamount of time has elapsed.